On Wed, 2008-01-09 at 20:52 -0800, Andrew Morgan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [Replying to everyone at once.] > > Yes, this is how I wanted to implement the per-process securebits thing. > This is also half of my original patch (from last year). > > The recent cap_bset changes have been implemented via prctl(), but in > that case the bset setting is done in the main kernel code and only > really honored in the capability LSM. This doesn't seem very modular to > me, and this prctl patch has the potential for better containing the > modularity for that code too. > > Since it is potentially useful for other LSMs, I thought I would break > it out to give it more visibility/discussion and to get a better sense > of whether it was acceptable or not. > > So far the objection (thanks Stephen for the historical context!) seems > to be "potential for abuse": > > ~ <[EMAIL PROTECTED]> > [PATCH] remove sys_security > > I've been auditing the LSM stuff a bit more.. > > They have registered an implemented a syscall, sys_security > that does nothing but switch into the individual modules > based on the first argument, i.e. it's ioctl() switching > on the security module instead of device node. Yuck. > > Patch below removes it (no intree users), maybe selinux/etc > folks should send their actual syscall for review instead.. > > Since SELinux is now 'in-tree', is this class of objection now moot?
I don't think so; it could still be abused by out-of-tree modules, and they really want to be able to carefully scrutinize additions to the kernel's syscall interface. I think you are better off directly implementing what you want in prctl() without worrying about LSM, as capabilities are still deeply intertwined with the core kernel (e.g. the capability bitmaps weren't pushed into LSM's security blobs). Or add a node to /proc/pid/attr for it. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
