Messages in this thread | | | Date | Mon, 08 Jun 2009 20:42:10 -0700 | From | Casey Schaufler <> | Subject | Re: [PATCH] integrity: fix IMA inode leak |
| |
Mimi Zohar wrote: > On Tue, 2009-06-09 at 09:16 +1000, James Morris wrote: > >> On Mon, 8 Jun 2009, Mimi Zohar wrote: >> >> >>> Ok, so instead of having a full fledge single security layer, only add >>> the security layer for those places where both the LSM hooks and IMA >>> co-exist: security_file_mmap, security_bprm_check, security_inode_alloc, >>> security_inode_free, and security_file_free. As the LSM hooks are called >>> 'security_XXXX', the call would look something like: >>> >>> security_all_inode_free() { >>> ima_inode_free() >>> security_inode_free() >>> } >>> >> Yes, it only needs to be a wrapper. The above is ugly, how about: >> > > agreed! But changing only these 5 security_ hook names and leaving the > rest alone is even uglier. > > >> security_inode_free() >> { >> ima_inode_free(); >> lsm_inode_free(); >> } >> >> I think we may have come full circle on the naming of the LSM hook, but >> 'security_*' was never great given that it's only supposed to be covering >> access control. >> > > so why not 'mac_'? >
An LSM could introduce a discretionary scheme. If you use SELinux with just MCS that's what you get. Although POSIX ACLs can't be implemented via the LSM (the mode bit interactions preclude doing so) there are other ACL schemes that could use the LSM. I have gotten suggestions on "label ownership" that would turn Smack into DAC. If you wanted to call it Additional Access Control (AAC) or Supplemental Access Control (SAC) I would go along with it, but not MAC.
> Mimi Zohar > > -- > 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/ > > >
| |