lkml.org 
[lkml]   [2007]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Out of tree module using LSM
    Alan Cox wrote
    > > Jargon File in all its glory. And if you still think you could look for
    > > patterns, how about executable code that self-modifies in random ways
    > > but when executed as a whole actually has the functionality of fetchmail
    > > embedded within it? How would you guard against that?
    >
    > Thats a problem for whoever writes the ESR detection tool and to what
    > level it works. The question for the kernel is how do we provide a
    > mechanism to allow (to some extent at least) this kind of tool to run.

    In a general way, what about providing a kind of {file,inode}_operations
    xchange functionality given a super_block such that filesystems could
    essentially be stacked, e.g. a

    int op_xchange(struct super_block *sb, struct inode_operations *new_iop,
    struct inode_operations *old_iop, struct file_operations *new_fop,
    struct file_operations *old_fop);

    The caller could/would/should be vetted, but replacing the static ops
    with new ones of the caller's specification would allow them to
    intercept the i/o, do whatever checking they wanted to do, and then call
    the proper underlying operation (even modifying the parameters, I guess,
    but that may be too weird). Perhaps separate get_* and set_* so that the
    caller can retrieve the current operations vector and only "override"
    the functions they really care about?

    It's not perfect, but as was recently pointed out, if you can only get
    98% of the way there rather than 100% is that a reason for not trying to
    make it possible? It'd obviously not work for mmap, but as near as I can
    tell the whole point is to get the "normal" malware cases without having
    to do icky things like mangle the syscall table.

    -justinb

    --
    Justin Banks
    BakBone Software
    justinb@bakbone.com
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-29 23:17    [W:2.282 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site