Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler <casey@schaufler-ca.com>]

On 12/12/2012 9:11 AM, Eric Paris wrote:
> On Wed, 2012-12-12 at 09:04 -0800, Casey Schaufler wrote:
>> On 12/12/2012 8:33 AM, Eric Paris wrote:
>> Yes, thank you.
>>
>> I'm headed in what I hope is a simpler direction. I have added
>> two files into securityfs:
>>
>> 	/sys/kernel/security/lsm     - a comma separated list of LSMs
>> 	/sys/kernel/security/present - the presented LSM
>>
>> I have also added LSM identified files in /proc/.../attr:
>>
>> 	/proc/.../attr/current
>> 	/proc/.../attr/selinux.current
>> 	/proc/.../attr/apparmor.current
>> 	/proc/.../attr/keycreate
>> 	/proc/.../attr/selinux.keycreate
>>
>> SELinux applications and libraries can use simple logic to determine
>> what to do:
>>
>> 	if /sys/kernel/security/lsm does not contain "selinux"
>> 		Stop! No SELinux here!
>> 	if /sys/kernel/security/present does not contain "selinux"
>> 		Use selinux.current
>> 	else
>> 		Use current if you like.
> So if I use legacy tools for SELinux and Apparmor with a stacking
> kernel, they will both load policy and get things started.  How would a
> legacy userspace know not to load it?  But then they will both
> use /proc/self/attr/current even though only one of them owns it.  So we
> get this half and half where one of them is enforcing a policy, but it
> can't actually really work...  Maybe we just don't care.  I'm ok with
> that answer.  If you don't update userspace, don't build your kernel
> that way   :)

We can't undo the sins of the past regarding /proc/.../attr. With
the scheme I'm putting forth you can have a working system with both
SELinux and AppArmor if either runtime understands the multiple LSM
environment. If neither understands, at least one will have trouble.

On a slightly different note, do we need a liblsm with interfaces like:

	int lsm_presented(char *presented)
	int lsm_supported(char *lsmname)

so you're not reading the files directly?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.