Re: Out of tree module using LSM

[Justin Banks]

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@xxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/