linux-kernel - Re: [PATCH] integrity: fix IMA inode leak

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 08 Jun 2009 20:42:10 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
CC:	James Morris <jmorris@...ei.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Mimi Zohar <zohar@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Serge Hallyn <serue@...ibm.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	David Safford <safford@...son.ibm.com>
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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>   
--
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/