Re: [PATCH v10] LSM: Multiple concurrent LSMs

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/11/2012 4:28 AM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> The /proc/*/attr interfaces are given to one LSM. This
>> can be done by setting CONFIG_SECURITY_PRESENT.
> I don't like CONFIG_SECURITY_PRESENT.
>
>>  int security_getprocattr(struct task_struct *p, char *name, char **value)
>>  {
>> -	return security_ops->getprocattr(p, name, value);
>> +	if (lsm_present)
>> +		return present_getprocattr(p, name, value);
>> +	return -EINVAL;
>>  }
>>  
>> -int security_setprocattr(struct task_struct *p, char *name, void *value, size_t size)
>> +int security_setprocattr(struct task_struct *p, char *name, void *value,
>> +				size_t size)
>>  {
>> -	return security_ops->setprocattr(p, name, value, size);
>> +	if (lsm_present)
>> +		return present_setprocattr(p, name, value, size);
>> +	return -EINVAL;
>>  }
> is what I meant but
>
>> +	/*
>> +	 * Use the LSM specified by CONFIG_SECURITY_PRESENT for
>> +	 * [gs]etprocattr. If the LSM specified is PRESENT_FIRST
>> +	 * use the first LSM to register that has the hooks.
>> +	 * If the specified LSM lacks the hooks treat it as if
>> +	 * there is no LSM registered that supplied them.
>> +	 */
>> +	if (ops->getprocattr && ops->setprocattr &&
>> +	    (!strcmp(ops->name, present_lsm) ||
>> +	     (!lsm_present && !strcmp(PRESENT_FIRST, present_lsm)))) {
>> +		lsm_present = ops;
>> +		present_getprocattr = ops->getprocattr;
>> +		present_setprocattr = ops->setprocattr;
>> +		pr_info("Security Module %s is presented in /proc.\n",
>> +			ops->name);
>> +	}
> is not what I meant.
>
> CONFIG_SECURITY_PRESENT must be always PRESENT_FIRST and only one LSM module
> which provides ops->getprocattr and/or ops->setprocattr is allowed to register.

No.
Absolutely not.

That restriction would make composing security modules completely
useless. At least for me. Sorry, but Smack + AppArmor is one of my
success criteria. I have introduced a smackfs/current interface
in this patch, but I plan to abandon that in favor of the enhanced
proc/.../attr entries we've been discussing.

I have not given up hope on secid using LSM combinations, either.
I really would prefer that there be no limitations.


> This is a mandatory requirement for not to break userspace tools for
> non-present LSM modules by supplying /proc/pid/attr/ interface that is
> malfunction for non-present LSM modules.
>
> 	/*
> 	 * Check for conflicting LSMs.
> 	 */
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
> 	if (ops->xfrm_policy_alloc_security &&
> 	    !list_empty(&lsm_hooks[LSM_xfrm_policy_alloc_security])) {
> 		pr_warn("LSM conflict on %s. %s not loaded.\n",
> 				"xfrm_policy_alloc_security", ops->name);
> 		return 0;
> 	}
> #endif
> 	if (ops->secid_to_secctx &&
> 	    !list_empty(&lsm_hooks[LSM_secid_to_secctx])) {
> 		pr_warn("LSM conflict on %s. %s not loaded.\n",
> 			"secid_to_secctx", ops->name);
> 		return 0;
> 	}
> 	if ((ops->getprocattr && !list_empty(&lsm_hooks[LSM_getprocattr])) ||
> 	    (ops->setprocattr && !list_empty(&lsm_hooks[LSM_setprocattr]))) {
> 		pr_warn("LSM conflict on %s. %s not loaded.\n",
> 			"getprocattr/setprocattr", ops->name);
> 		return 0;
> 	}
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 4:59 AM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> On 12/11/2012 4:28 AM, Tetsuo Handa wrote:
>>> CONFIG_SECURITY_PRESENT must be always PRESENT_FIRST and only one LSM module
>>> which provides ops->getprocattr and/or ops->setprocattr is allowed to register.
>> No.
>> Absolutely not.
>>
>> That restriction would make composing security modules completely
>> useless. At least for me. Sorry, but Smack + AppArmor is one of my
>> success criteria. I have introduced a smackfs/current interface
>> in this patch, but I plan to abandon that in favor of the enhanced
>> proc/.../attr entries we've been discussing.
> My suggestion was
>
>   Step 1: Start LSM stacking without supporting "SELinux + AppArmor" or
>           "SMACK + AppArmor".

I will repeat myself.

No.
Absolutely not.

>   Step 2: Wait for a year or so for migrating from conflicting /proc/pid/attr/
>           interface to non-conflicting interfaces.

No. I don't have another year to wait. Were I willing to wait
I'd have let someone else try to wrestle this elephant.

>   Step 3: Kill conflicting /proc/pid/attr/ interface and support
>           "SELinux + AppArmor" or "SMACK + AppArmor" so that not-yet-migrated
>           userspace tools no longer recognize that "LSM is enabled" rather than
>           recognize that "LSM is enabled" but cannot work correctly.

The problem here is that I can't kill the old interfaces. Ever.
Some 2nd Lieutenant in Gaithersburg is busy installing a RHEL system
right now for which he spent the past two years getting approval.
It has classified programs on it. It will run until he makes Colonel.
The "security interfaces" will not change, and that means no updates
once the old attr interfaces go away. 

>
> but your will is
>
>   Step 1: Start LSM stacking with supporting "SELinux + AppArmor" or
>           "SMACK + AppArmor" with tolerating malfunctioningly working userspace
>           tools.

You're suggesting that we don't change the kernel until the
applications are fixed. No one is going to change the applications
until the kernel is fixed.

>
> isn't it?
>
> I suggested you to *eventually* break not-yet-migrated userspace tools in order
> to *eventually* make it possible to stack "SELinux + AppArmor" or
> "SMACK + AppArmor". 
>
> You purposely *immediately* break non-present LSM module's userspace tools in
> order to *immediately* make it possible to stack "SELinux + AppArmor" or
> "SMACK + AppArmor".
>
> But I'm fine with your will provided that SELinux/SMACK/AppArmor developers and
> their users can agree with your will.

I'm also making development of tools for the multiple LSM case
possible. Someone has to lead.

>> I have not given up hope on secid using LSM combinations, either.
>> I really would prefer that there be no limitations.
>>
>>
>>> This is a mandatory requirement for not to break userspace tools for
>>> non-present LSM modules by supplying /proc/pid/attr/ interface that is
>>> malfunction for non-present LSM modules.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Wed, 2012-12-12 at 07:48 -0800, Casey Schaufler wrote:

How about asking every LSM to implement a new 'enable' function.  If the
LSM is not 'present' only the new 'enable' function can be used.  If the
LSM is present either the legacy enable function every LSM uses today or
the new enable function can be used.  Thus even if you build the kernel
with stacking, you cannot enable a non-present LSM unless the tools have
been updated.

I'd envision for SELinux it would mean that we would disable/not
expose/whatever /sys/fs/selinux/load when SELinux was not present.  And
we'd have a new /sys/fs/selinux/new_load which could be used in its
place.

Thoughts?

-Eric


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 7:55 AM, Eric Paris wrote:
> On Wed, 2012-12-12 at 07:48 -0800, Casey Schaufler wrote:
>
> How about asking every LSM to implement a new 'enable' function.  If the
> LSM is not 'present' only the new 'enable' function can be used.  If the
> LSM is present either the legacy enable function every LSM uses today or
> the new enable function can be used.  Thus even if you build the kernel
> with stacking, you cannot enable a non-present LSM unless the tools have
> been updated.

I'm sorry, but I am having trouble understanding what you're suggesting.

>
> I'd envision for SELinux it would mean that we would disable/not
> expose/whatever /sys/fs/selinux/load when SELinux was not present.  And
> we'd have a new /sys/fs/selinux/new_load which could be used in its
> place.
>
> Thoughts?
>
> -Eric
>
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Wed, 2012-12-12 at 08:24 -0800, Casey Schaufler wrote:
> On 12/12/2012 7:55 AM, Eric Paris wrote:
> > On Wed, 2012-12-12 at 07:48 -0800, Casey Schaufler wrote:
> >
> > How about asking every LSM to implement a new 'enable' function.  If the
> > LSM is not 'present' only the new 'enable' function can be used.  If the
> > LSM is present either the legacy enable function every LSM uses today or
> > the new enable function can be used.  Thus even if you build the kernel
> > with stacking, you cannot enable a non-present LSM unless the tools have
> > been updated.
> 
> I'm sorry, but I am having trouble understanding what you're suggesting.

I'm believing every LSM has some mechanism by which it is 'enabled' at
run time.  With SELinux that mechanism is loading policy.  If you don't
load policy SELinux will not enforce anything.  I'm assuming something
similar exists for others.  Tell me if I'm wrong.

We know that legacy tools will break on an LSM if it is not
CONFIG_SECURITY_PRESET (or equivalent 'first in list').  I'm calling
this first LSM the 'present' LSM.

Legacy tools also will attempt to enable their LSM using the current
enabling interface.  For SELinux this is /sys/fs/selinux/load

Thus if as part of stacking we implement a new enabling interface for
each LSM and disable the legacy enabling mechanism when the LSM is not
present we make sure that new kernels can't get into the half and half
situation with old userspace.

Legacy 'enable' interface is /sys/fs/selinux/load
New enabling interface could be /sys/fs/selinux/new_load

In SELinux present mode, they would do the exact same thing.  In SELinux
non-present mode we could disable /sys/fs/selinux/load and only allow
new_load.  Thus old userspace cannot 'enable' SELinux on a new kernel
when it won't work.

Make any more sense?


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 8:33 AM, Eric Paris wrote:
> On Wed, 2012-12-12 at 08:24 -0800, Casey Schaufler wrote:
>> On 12/12/2012 7:55 AM, Eric Paris wrote:
>>> On Wed, 2012-12-12 at 07:48 -0800, Casey Schaufler wrote:
>>>
>>> How about asking every LSM to implement a new 'enable' function.  If the
>>> LSM is not 'present' only the new 'enable' function can be used.  If the
>>> LSM is present either the legacy enable function every LSM uses today or
>>> the new enable function can be used.  Thus even if you build the kernel
>>> with stacking, you cannot enable a non-present LSM unless the tools have
>>> been updated.
>> I'm sorry, but I am having trouble understanding what you're suggesting.
> I'm believing every LSM has some mechanism by which it is 'enabled' at
> run time.  With SELinux that mechanism is loading policy.  If you don't
> load policy SELinux will not enforce anything.  I'm assuming something
> similar exists for others.  Tell me if I'm wrong.
>
> We know that legacy tools will break on an LSM if it is not
> CONFIG_SECURITY_PRESET (or equivalent 'first in list').  I'm calling
> this first LSM the 'present' LSM.
>
> Legacy tools also will attempt to enable their LSM using the current
> enabling interface.  For SELinux this is /sys/fs/selinux/load
>
> Thus if as part of stacking we implement a new enabling interface for
> each LSM and disable the legacy enabling mechanism when the LSM is not
> present we make sure that new kernels can't get into the half and half
> situation with old userspace.
>
> Legacy 'enable' interface is /sys/fs/selinux/load
> New enabling interface could be /sys/fs/selinux/new_load
>
> In SELinux present mode, they would do the exact same thing.  In SELinux
> non-present mode we could disable /sys/fs/selinux/load and only allow
> new_load.  Thus old userspace cannot 'enable' SELinux on a new kernel
> when it won't work.
>
> Make any more sense?
>
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.


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

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   :)


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

/proc/filesystems to look for selinuxfs

then /proc/mounts to find selinuxfs assuming it isn't at
/sys/fs/selinux or /selinux

I'd guess it is ssh failing closed, not the library, but in either
case, it's the right thing to do in enforcing and could probably be
considered a bug in permissive...

On Wed, Dec 12, 2012 at 12:16 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Dec 12, 2012 at 9:11 AM, Eric Paris <eparis@redhat.com> 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   :)
>
> That's my way of looking at it -- using more than one LSM that uses
> attr/current with old userspace lands you in a very confusing place.
> E.g. with the current patch, if SELinux is stacked but not presented,
> all the SELinux libraries fail closed and I can't SSH in. :)
>
> I haven't checked to see how the libraries are deciding that SELinux
> is built-in (/sys/modules? securityfs?) It feels like trying to use
> this kernel feature without userspace support should be considered a
> 'bad idea'. :) Building a kernel without stacked (conflicting) LSMs,
> everything continues to work fine.
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Wed, Dec 12, 2012 at 12:31 PM, Casey Schaufler
<casey@schaufler-ca.com> wrote:

> We can't undo the sins of the past regarding /proc/.../attr.

Agreed

> 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.

Agreed.  (assuming the command line option was configured to present
the one that doesn't understand)

> If neither understands, at least one will have trouble.

Agreed.  I'm just of the belief the 'trouble' should be 'fails
completely' rather than 'fails partially' trying to use
/proc/self/attr...

> 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?

If I have new enough userspace to call such functions, do I need them?
 Doesn't seem I need presented.  I can always use the selinux.*
version of attr files.  Maybe lsm_supported is slightly useful.  We
don't have to parse /proc/filesystems looking for selinuxfs.  I guess
that'd be faster, but I don't know if others would use it...

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 9:47 AM, Eric Paris wrote:
> On Wed, Dec 12, 2012 at 12:31 PM, Casey Schaufler
> <casey@schaufler-ca.com> wrote:
>
>> We can't undo the sins of the past regarding /proc/.../attr.
> Agreed
>
>> 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.
> Agreed.  (assuming the command line option was configured to present
> the one that doesn't understand)
>
>> If neither understands, at least one will have trouble.
> Agreed.  I'm just of the belief the 'trouble' should be 'fails
> completely' rather than 'fails partially' trying to use
> /proc/self/attr...

Configure None as the presented LSM and all legacy userspace
will fail. Trouble for all.

>
>> 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?
> If I have new enough userspace to call such functions, do I need them?
>  Doesn't seem I need presented.  I can always use the selinux.*
> version of attr files.  Maybe lsm_supported is slightly useful.  We
> don't have to parse /proc/filesystems looking for selinuxfs.  I guess
> that'd be faster, but I don't know if others would use it...
>
> --
> 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.
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Wed, Dec 12, 2012 at 1:25 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:

> Configure None as the presented LSM and all legacy userspace
> will fail. Trouble for all.

I think the question is when and how it fails.  I'd like SELinux to
fail really early and in some clean way if it is non-present and you
don't have new userspace.  I'd rather it fail on policy load than on
some later /proc/*/attr/ issue.  I can do it myself even if you don't
want to do it as part of the stacking work.

My current thought is a required ioctl before policy load if
non-present otherwise reject policy load instead of the entirely new
policy load file.

-Eric

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 10:47 AM, Eric Paris wrote:
> On Wed, Dec 12, 2012 at 1:25 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> Configure None as the presented LSM and all legacy userspace
>> will fail. Trouble for all.
> I think the question is when and how it fails.  I'd like SELinux to
> fail really early and in some clean way if it is non-present and you
> don't have new userspace.  I'd rather it fail on policy load than on
> some later /proc/*/attr/ issue.  I can do it myself even if you don't
> want to do it as part of the stacking work.

So the problem would be old userspace (new userspace can query
/sys/kernel/security/lsm and /sys/kernel/security/present) with
a kernel configured with present=apparmor.

You want loading SELinux policy to fail in this case, because
you know that the system isn't going to work properly. You are
suggesting a kernel change that inhibits loading the SELinux
policy unless userspace tells the kernel it is OK to do so
if present is not selinux.

I have no objection to such. You could look at CONFIG_PRESENT_SECURITY
in the SELinux initialization code and set a "don't load" trigger if
it isn't "selinux". Your selinuxfs (or some other) interface could
allow the trigger to get unset by the updated userspace.

 

>
> My current thought is a required ioctl before policy load if
> non-present otherwise reject policy load instead of the entirely new
> policy load file.
>
> -Eric
>
> --
> 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.
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Wed, Dec 12, 2012 at 3:46 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:

> You want loading SELinux policy to fail in this case, because
> you know that the system isn't going to work properly. You are
> suggesting a kernel change that inhibits loading the SELinux
> policy unless userspace tells the kernel it is OK to do so
> if present is not selinux.

Now you get me.  I just don't understand why all LSMs wouldn't want
this.  If they know they will fail, they should fail early and cleanly
rather than unpredictably later.  If you LSM can't fail due to attr
issues, this doesn't apply.

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/12/2012 12:51 PM, Eric Paris wrote:
> On Wed, Dec 12, 2012 at 3:46 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> You want loading SELinux policy to fail in this case, because
>> you know that the system isn't going to work properly. You are
>> suggesting a kernel change that inhibits loading the SELinux
>> policy unless userspace tells the kernel it is OK to do so
>> if present is not selinux.
> Now you get me.  I just don't understand why all LSMs wouldn't want
> this.  If they know they will fail, they should fail early and cleanly
> rather than unpredictably later.  If you LSM can't fail due to attr
> issues, this doesn't apply.
>
Ah. Any LSM see it, but each LSM is going to have to decide
what it does about it. SELinux can refuse to load policy.
Smack is perfectly happy to run without any rules set. There
is no major configuration event to fail.

Smack will be aggressively updating userspace. Smack does not
(alas) have the install base that SELinux enjoys. I am not
especially concerned for Smack, while I understand fully the
SELinux concern.


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Thu, Dec 13, 2012 at 7:06 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Casey Schaufler wrote:

>>       /proc/.../attr/current
>>       /proc/.../attr/selinux.current
>>       /proc/.../attr/apparmor.current
>>       /proc/.../attr/keycreate
>>       /proc/.../attr/selinux.keycreate
>>

> Can we use prctl() interface instead of /proc/$pid/attr/$lsmname.$type ?
> I simply don't want to see flood of entries when "find /proc/" runs. ;-)
>
> prctl() can tell the caller whether specified LSM is enabled/presented or not
> via its return value.

I don't much care for or understand Casey's reason for using selinux.*
instead of selinux/* but at least it means we can interact with these
interfaces in a shell.  prctl() means you can't use tools like cat or
echo.  Everything has to be a utility.  That just does not seem as
nice for admins.

In my opinion you want to do things pragmatically, use a library, and
if you want to do things as a human, use the tools that already exist.

-Eric

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/13/2012 8:12 AM, Eric Paris wrote:
> On Thu, Dec 13, 2012 at 7:06 AM, Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> Casey Schaufler wrote:
>>>       /proc/.../attr/current
>>>       /proc/.../attr/selinux.current
>>>       /proc/.../attr/apparmor.current
>>>       /proc/.../attr/keycreate
>>>       /proc/.../attr/selinux.keycreate
>>>
>> Can we use prctl() interface instead of /proc/$pid/attr/$lsmname.$type ?
>> I simply don't want to see flood of entries when "find /proc/" runs. ;-)
>>
>> prctl() can tell the caller whether specified LSM is enabled/presented or not
>> via its return value.
> I don't much care for or understand Casey's reason for using selinux.*
> instead of selinux/*

I asked opinions and all I heard were crickets. It's an easy change.
Does anyone else have a preference?

> but at least it means we can interact with these
> interfaces in a shell.  prctl() means you can't use tools like cat or
> echo.  Everything has to be a utility.  That just does not seem as
> nice for admins.

Most programming is being done in scripting languages these days.
Eric is correct. It is much more sensible to burden the C programmer
than the HTML5 programmer. For many, many reasons.

> In my opinion you want to do things pragmatically, use a library, and
> if you want to do things as a human, use the tools that already exist.
>
> -Eric
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/13/2012 4:06 AM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> You're suggesting that we don't change the kernel until the
>> applications are fixed. No one is going to change the applications
>> until the kernel is fixed.
> People *can* change the applications before the kernel is changed if clear
> specification is provided. That's why my approach has migration period.

Of course they *can*, they just *won't*. The whole discussion
is based on the fact that people resist change so strenuously.

>> 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.
>>
> Can we use prctl() interface instead of /proc/$pid/attr/$lsmname.$type ?
> I simply don't want to see flood of entries when "find /proc/" runs. ;-)

That cat is so long out of the bag that it's been adopted and spayed.

>
> prctl() can tell the caller whether specified LSM is enabled/presented or not
> via its return value.
>
> I think we can provide a simple utility that maps
>
>   echo something > /proc/pid/attr/selinux.current
>
> to
>
>   prctl(PR_SET_SECURITY, pid, "selinux", "current", "something")
>
> and
>
>   cat /proc/pid/attr/selinux.current
>
> to
>
>   prctl(PR_GET_SECURITY, pid, "selinux", "current", buffer)
>
> for calling prctl() from script programs.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Eric Paris]

On Fri, Dec 14, 2012 at 9:26 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:

> Are you worrying about breakage that taskattr runs as a child process until
> taskattr utility is implemented as a shell's built-in function like echo ?
> Then, we can have migration period.
>
> I don't see much difference because scripts programmers have to convert their
> scripts anyway...

Please no. We already have that utility, it's called 'cat' and 'echo'
and everyone already knows them and has them installed.  If you want
to interact with a C program, it's super easy to write a library
function that deals with a file interface.  Maybe it's a poor
argument, but a file interface is the unix way to do things.  Its just
what people expect.  Forcing some new utility on them only makes it
harder.

You might be able to implement a prctl interface for your LSM, if you
really think there is some value, but I doubt it.  I'd expect others
to want you to either use netlink or ioctl rather than prctl.

In any case, I support /proc/pid/attr/[LSM]/[LSM_FILES]

> Kees Cook wrote:
>> Like Eric, I prefer directories. It complicates things slightly
>> because then LSMs can't be named "current", etc...
>
> LSMs can't be named ".", "..", "/" etc...

I think these restrictions sound most reasonable.

--
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.

Re: [PATCH v10] LSM: Multiple concurrent LSMs

[Casey Schaufler]

On 12/13/2012 9:13 AM, Kees Cook wrote:
> On Thu, Dec 13, 2012 at 8:31 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 12/13/2012 8:12 AM, Eric Paris wrote:
>>> On Thu, Dec 13, 2012 at 7:06 AM, Tetsuo Handa
>>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>>> Casey Schaufler wrote:
>>>>>       /proc/.../attr/current
>>>>>       /proc/.../attr/selinux.current
>>>>>       /proc/.../attr/apparmor.current
>>>>>       /proc/.../attr/keycreate
>>>>>       /proc/.../attr/selinux.keycreate
>>>>>
>>>> Can we use prctl() interface instead of /proc/$pid/attr/$lsmname.$type ?
>>>> I simply don't want to see flood of entries when "find /proc/" runs. ;-)
>>>>
>>>> prctl() can tell the caller whether specified LSM is enabled/presented or not
>>>> via its return value.
>>> I don't much care for or understand Casey's reason for using selinux.*
>>> instead of selinux/*
>> I asked opinions and all I heard were crickets. It's an easy change.
>> Does anyone else have a preference?
> Like Eric, I prefer directories. It complicates things slightly
> because then LSMs can't be named "current", etc...

I have been digging at the code and "selinux.current" is a whole
lot simpler than "selinux/current". fs/proc/base.c is where to look
at the code. For now I'm sticking with my original plan. If someone
cares enough to suggest an implementation, I'm wide open to it.


--
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.