linux-kernel - Re: Out of tree module using LSM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Nov 2007 15:12:38 -0700
From:	Justin Banks <justinb@...bone.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jon Masters <jonathan@...masters.org>,
	Ray Lee <ray-lk@...rabbit.org>, tvrtko.ursulin@...hos.com,
	Al Viro <viro@....linux.org.uk>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, Valdis.Kletnieks@...edu
Subject: Re: 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@...bone.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/