Subject: [PATCH v13 0/9] LSM: Multiple concurrent LSMs
Change the infrastructure for Linux Security Modules (LSM)s from a
single vector of hook handlers to a list based method for handling
multiple concurrent modules.
The "security=" boot option takes a comma separated list of LSMs,
registering them in the order presented. The LSM hooks will be
executed in the order registered. Hooks that return errors are
not short circuited. All hooks are called even if one of the LSM
hooks fails. The result returned will be that of the last LSM
hook that failed.
All behavior from security/capability.c has been moved into
the hook handling. The security/commoncap functions used
to get called from the LSM specific code. The handling of the
capability functions has been moved out of the LSMs and into the
hook handling.
A level of indirection has been introduced in the handling of
security blobs. LSMs no longer access ->security fields directly,
instead they use an abstraction provided by lsm_[gs]et field
functions.
The notion that "the security context" can be represented as a
single u32 "secid" does not scale to the case where multiple LSMs
want to provide "the security context". There are two types of
use for secids, logging and networking. Logging is addressed by
replacing the secid with a set of secids. Networking is addressed
by allocating each scheme to a specific LSM.
The NetLabel, XFRM and secmark facilities are restricted to use
by one LSM at a time. This is due to limitations of the underlying
networking mechanisms. The good news is that viable configurations
can be created. The bad news is that the complexity of configuring
a system is necessarily increased.
The /proc/*/attr interfaces are given to one LSM. This can be
done by setting CONFIG_SECURITY_PRESENT. Additional interfaces
have been created in /proc/*/attr so that each LSM has its own
named interfaces.
A "security context" may now contrain information processed by
more than one LSM. The proper form of a security context identifies
the information it contains by LSM:
smack='Pop'selinux='system_u:object_r:etc_r:s0'
A security context without the LSM identifying lsm='<text>' gets
passed through to all of the LSMs that use a security context. This
maintains compatability in the case where there is only one LSM
using the security context.
Signed-off-by: Casey Schaufler <[email protected]>
---
Documentation/security/LSM.txt | 39 +-
drivers/usb/core/devio.c | 10 +-
fs/proc/base.c | 29 +-
fs/sysfs/dir.c | 3 +-
fs/sysfs/inode.c | 5 +-
fs/sysfs/sysfs.h | 7 +-
fs/xattr.c | 8 +-
include/linux/audit.h | 9 +-
include/linux/cred.h | 3 +-
include/linux/lsm.h | 167 ++
include/linux/sched.h | 2 +-
include/linux/security.h | 378 +++-
include/net/af_unix.h | 3 +-
include/net/netlabel.h | 3 +-
include/net/scm.h | 8 +-
include/net/xfrm.h | 4 +-
kernel/audit.c | 94 +-
kernel/audit.h | 4 +-
kernel/auditfilter.c | 21 +-
kernel/auditsc.c | 80 +-
kernel/cred.c | 6 +-
kernel/signal.c | 6 +-
net/ipv4/ip_sockglue.c | 8 +-
.../netfilter/nf_conntrack_l3proto_ipv4_compat.c | 11 +-
net/netfilter/nf_conntrack_netlink.c | 24 +-
net/netfilter/nf_conntrack_standalone.c | 11 +-
net/netfilter/xt_SECMARK.c | 4 +-
net/netlabel/netlabel_kapi.c | 37 +-
net/netlabel/netlabel_unlabeled.c | 22 +-
net/netlabel/netlabel_user.c | 4 +-
net/netlabel/netlabel_user.h | 61 +-
net/unix/af_unix.c | 17 +-
net/xfrm/xfrm_user.c | 16 +-
security/Kconfig | 176 +-
security/Makefile | 3 +-
security/apparmor/context.c | 10 +-
security/apparmor/domain.c | 19 +-
security/apparmor/include/context.h | 13 +-
security/apparmor/lsm.c | 68 +-
security/capability.c | 1105 -----------
security/commoncap.c | 6 -
security/inode.c | 79 +-
security/integrity/ima/ima_policy.c | 7 +-
security/security.c | 2014 ++++++++++++++++----
security/selinux/hooks.c | 412 ++--
security/selinux/include/objsec.h | 2 +
security/selinux/include/xfrm.h | 2 +-
security/selinux/netlabel.c | 17 +-
security/selinux/selinuxfs.c | 6 +-
security/selinux/xfrm.c | 9 +-
security/smack/smack.h | 15 +-
security/smack/smack_access.c | 2 +-
security/smack/smack_lsm.c | 474 +++--
security/smack/smackfs.c | 56 +-
security/tomoyo/common.h | 6 +-
security/tomoyo/domain.c | 2 +-
security/tomoyo/securityfs_if.c | 9 +-
security/tomoyo/tomoyo.c | 49 +-
security/yama/Kconfig | 7 -
security/yama/yama_lsm.c | 35 +-
60 files changed, 3357 insertions(+), 2350 deletions(-)
On Tuesday, April 23, 2013 09:04:06 AM Casey Schaufler wrote:
> Subject: [PATCH v13 0/9] LSM: Multiple concurrent LSMs
>
> Change the infrastructure for Linux Security Modules (LSM)s from a
> single vector of hook handlers to a list based method for handling
> multiple concurrent modules.
>
> The "security=" boot option takes a comma separated list of LSMs,
> registering them in the order presented. The LSM hooks will be
> executed in the order registered. Hooks that return errors are
> not short circuited. All hooks are called even if one of the LSM
> hooks fails. The result returned will be that of the last LSM
> hook that failed.
...
> The NetLabel, XFRM and secmark facilities are restricted to use
> by one LSM at a time. This is due to limitations of the underlying
> networking mechanisms. The good news is that viable configurations
> can be created. The bad news is that the complexity of configuring
> a system is necessarily increased.
I know we had a good discussion about this a while back and I just wanted to
hear from you about this current patchset; how does the labeled networking LSM
assignment work? Is it first-come-first-served based on the 'security='
setting?
--
paul moore
http://www.paul-moore.com
On 4/24/2013 11:57 AM, Paul Moore wrote:
> On Tuesday, April 23, 2013 09:04:06 AM Casey Schaufler wrote:
>> Subject: [PATCH v13 0/9] LSM: Multiple concurrent LSMs
>>
>> Change the infrastructure for Linux Security Modules (LSM)s from a
>> single vector of hook handlers to a list based method for handling
>> multiple concurrent modules.
>>
>> The "security=" boot option takes a comma separated list of LSMs,
>> registering them in the order presented. The LSM hooks will be
>> executed in the order registered. Hooks that return errors are
>> not short circuited. All hooks are called even if one of the LSM
>> hooks fails. The result returned will be that of the last LSM
>> hook that failed.
> ...
>
>> The NetLabel, XFRM and secmark facilities are restricted to use
>> by one LSM at a time. This is due to limitations of the underlying
>> networking mechanisms. The good news is that viable configurations
>> can be created. The bad news is that the complexity of configuring
>> a system is necessarily increased.
> I know we had a good discussion about this a while back and I just wanted to
> hear from you about this current patchset; how does the labeled networking LSM
> assignment work? Is it first-come-first-served based on the 'security='
> setting?
It's explicitly set in security/Kconfig. The problem with
first-come-first-serve is that the LSMs don't actually register
in the order specified, either at build time or boot time.
Further, until the init phase is complete, you don't know which
LSMs are actually going to register. That, and I promised Tetsuo
I wouldn't go out of my way to prevent late module loading in
the future.
I could do order checking on module registration and take
the networking component away from an LSM that registered
earlier, but with a larger order number I suppose.
The default configuration gives xfrm and secmark to SELinux
and NetLabel to Smack. If Smack is not included NetLabel goes
to SELinux. When LSMs using any of these facilities are added
in the future we'll have to negotiate the defaults.
An interesting aside that may be relevant is that the error
condition behavior makes it advisable to have the LSM you care
about most go last. If the networking components were strictly
FCFS you might have to chose an ordering you might not want for
other reasons.
It would be possible to have a boot time specification for
the networking components if you think it's important. I do
worry about making it excessively complicated. I'd be much more
concerned if more LSMs used the networking components.
On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
> On 4/24/2013 11:57 AM, Paul Moore wrote:
> > I know we had a good discussion about this a while back and I just wanted
> > to hear from you about this current patchset; how does the labeled
> > networking LSM assignment work? Is it first-come-first-served based on
> > the 'security=' setting?
>
> It's explicitly set in security/Kconfig. The problem with
> first-come-first-serve is that the LSMs don't actually register
> in the order specified, either at build time or boot time.
> Further, until the init phase is complete, you don't know which
> LSMs are actually going to register. That, and I promised Tetsuo
> I wouldn't go out of my way to prevent late module loading in
> the future.
>
> I could do order checking on module registration and take
> the networking component away from an LSM that registered
> earlier, but with a larger order number I suppose.
Hmmm. How difficult would it be to enforce the order during LSM registration?
As discussed previously, I'm not a big fan of assigning the network controls
at compile time when the LSMs can be toggled at boot time.
The real solution is to just get the netdev folks to accept a security blob in
the sk_buff so we can fix this (and many other problems) once and for all. I
still haven't given up on this effort but I think it would be silly to hold up
the stacking effort for the sk_buff security blob.
> The default configuration gives xfrm and secmark to SELinux
> and NetLabel to Smack. If Smack is not included NetLabel goes
> to SELinux. When LSMs using any of these facilities are added
> in the future we'll have to negotiate the defaults.
The defaults are always going to be wrong for someone.
> An interesting aside that may be relevant is that the error
> condition behavior makes it advisable to have the LSM you care
> about most go last. If the networking components were strictly
> FCFS you might have to chose an ordering you might not want for
> other reasons.
Well, maybe not ... I think. If we take a FCFS approach to the network
controls then only one LSM is really ever going to throw an error on the
network hooks, yes?
> It would be possible to have a boot time specification for
> the networking components if you think it's important. I do
> worry about making it excessively complicated. I'd be much more
> concerned if more LSMs used the networking components.
I think the "excessively complicated" boat has already sailed :)
I'm still in favor of assigning the network hooks to the LSM at boot based on
the "security=" configuration.
--
paul moore
http://www.paul-moore.com
On 04/24/2013 02:15 PM, Paul Moore wrote:
> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>> On 4/24/2013 11:57 AM, Paul Moore wrote:
>>> I know we had a good discussion about this a while back and I just wanted
>>> to hear from you about this current patchset; how does the labeled
>>> networking LSM assignment work? Is it first-come-first-served based on
>>> the 'security=' setting?
>>
>> It's explicitly set in security/Kconfig. The problem with
>> first-come-first-serve is that the LSMs don't actually register
>> in the order specified, either at build time or boot time.
>> Further, until the init phase is complete, you don't know which
>> LSMs are actually going to register. That, and I promised Tetsuo
>> I wouldn't go out of my way to prevent late module loading in
>> the future.
>>
>> I could do order checking on module registration and take
>> the networking component away from an LSM that registered
>> earlier, but with a larger order number I suppose.
>
> Hmmm. How difficult would it be to enforce the order during LSM registration?
> As discussed previously, I'm not a big fan of assigning the network controls
> at compile time when the LSMs can be toggled at boot time.
>
> The real solution is to just get the netdev folks to accept a security blob in
> the sk_buff so we can fix this (and many other problems) once and for all. I
> still haven't given up on this effort but I think it would be silly to hold up
> the stacking effort for the sk_buff security blob.
>
>> The default configuration gives xfrm and secmark to SELinux
>> and NetLabel to Smack. If Smack is not included NetLabel goes
>> to SELinux. When LSMs using any of these facilities are added
>> in the future we'll have to negotiate the defaults.
>
> The defaults are always going to be wrong for someone.
>
>> An interesting aside that may be relevant is that the error
>> condition behavior makes it advisable to have the LSM you care
>> about most go last. If the networking components were strictly
>> FCFS you might have to chose an ordering you might not want for
>> other reasons.
>
> Well, maybe not ... I think. If we take a FCFS approach to the network
> controls then only one LSM is really ever going to throw an error on the
> network hooks, yes?
>
>> It would be possible to have a boot time specification for
>> the networking components if you think it's important. I do
>> worry about making it excessively complicated. I'd be much more
>> concerned if more LSMs used the networking components.
>
> I think the "excessively complicated" boat has already sailed :)
>
> I'm still in favor of assigning the network hooks to the LSM at boot based on
> the "security=" configuration.
>
yeah dealing with selection at boot time is going to be needed
at some point, whether its now or later ...
On 4/24/2013 4:00 PM, John Johansen wrote:
> On 04/24/2013 02:15 PM, Paul Moore wrote:
>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>>> On 4/24/2013 11:57 AM, Paul Moore wrote:
>>>> I know we had a good discussion about this a while back and I just wanted
>>>> to hear from you about this current patchset; how does the labeled
>>>> networking LSM assignment work? Is it first-come-first-served based on
>>>> the 'security=' setting?
>>> It's explicitly set in security/Kconfig. The problem with
>>> first-come-first-serve is that the LSMs don't actually register
>>> in the order specified, either at build time or boot time.
>>> Further, until the init phase is complete, you don't know which
>>> LSMs are actually going to register. That, and I promised Tetsuo
>>> I wouldn't go out of my way to prevent late module loading in
>>> the future.
>>>
>>> I could do order checking on module registration and take
>>> the networking component away from an LSM that registered
>>> earlier, but with a larger order number I suppose.
>> Hmmm. How difficult would it be to enforce the order during LSM registration?
>> As discussed previously, I'm not a big fan of assigning the network controls
>> at compile time when the LSMs can be toggled at boot time.
>>
>> The real solution is to just get the netdev folks to accept a security blob in
>> the sk_buff so we can fix this (and many other problems) once and for all. I
>> still haven't given up on this effort but I think it would be silly to hold up
>> the stacking effort for the sk_buff security blob.
Fighting with hardcore networking people isn't my
idea of fun either. Waiting for them to approve of
a security facility has never been a winning strategy.
>>> The default configuration gives xfrm and secmark to SELinux
>>> and NetLabel to Smack. If Smack is not included NetLabel goes
>>> to SELinux. When LSMs using any of these facilities are added
>>> in the future we'll have to negotiate the defaults.
>> The defaults are always going to be wrong for someone.
>>
>>> An interesting aside that may be relevant is that the error
>>> condition behavior makes it advisable to have the LSM you care
>>> about most go last. If the networking components were strictly
>>> FCFS you might have to chose an ordering you might not want for
>>> other reasons.
>> Well, maybe not ... I think. If we take a FCFS approach to the network
>> controls then only one LSM is really ever going to throw an error on the
>> network hooks, yes?
You set up the order you want to get the networking handled
correctly and you could get filesystem hooks in the wrong order.
Not that that really ought to be a problem, but there are wonky
admin tools out there.
>>> It would be possible to have a boot time specification for
>>> the networking components if you think it's important. I do
>>> worry about making it excessively complicated. I'd be much more
>>> concerned if more LSMs used the networking components.
>> I think the "excessively complicated" boat has already sailed :)
Fair enough.
>> I'm still in favor of assigning the network hooks to the LSM at boot based on
>> the "security=" configuration.
>>
> yeah dealing with selection at boot time is going to be needed
> at some point, whether its now or later ...
I'll have a go at it then. What that would mean is that:
security=smack,selinux
gives Smack NetLabel and SELinux xfrm and secmark while
security=selinux,smack
gives SELinux all three. I would still like it to be possible to
explicitly configure the allocation at build time.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Casey Schaufler wrote:
> >> I'm still in favor of assigning the network hooks to the LSM at boot based on
> >> the "security=" configuration.
> >>
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
>
> I'll have a go at it then. What that would mean is that:
>
> security=smack,selinux
>
> gives Smack NetLabel and SELinux xfrm and secmark while
>
> security=selinux,smack
>
> gives SELinux all three. I would still like it to be possible to
> explicitly configure the allocation at build time.
The problem is that it is difficult to control the registration order since
each LSM module directly calls security_initcall() for registering themselves?
Then, what about replacing
static int __init foo_init()
{
register_security(&foo_security_ops);
return 0;
}
security_initcall(foo_init);
static int __init bar_init()
{
register_security(&bar_security_ops);
return 0;
}
security_initcall(bar_init);
with
static int __init foo_init()
{
register_security(&foo_security_ops);
return 0;
}
static int __init bar_init()
{
register_security(&bar_security_ops);
return 0;
}
static int __init add_foo(void) {
foo_security_ops.register = foo_init;
list_add_tail(&foo_security_ops.list[lsm_candidate], &lsm_hooks[lsm_candidate]);
return 0;
}
pure_initcall(add_foo);
static int __init add_bar(void) {
bar_security_ops.register = bar_init;
list_add_tail(&bar_security_ops.list[lsm_candidate], &lsm_hooks[lsm_candidate]);
return 0;
}
pure_initcall(add_bar);
and let security/security.c register in accordance with
security= parameter (or compile-time config if none given)?
static int __init register_lsms(void)
{
for_each_comma_separated_lsm_names_given() {
bool found = 0;
list_for_each_entry_safe(ops, tmp, &lsm_hooks[lsm_candidate]) {
if (!strcmp(ops->name, name)) {
if (ops->register() == 0)
list_del(&ops->list[lsm_candidate]);
found = 1;
break;
}
}
if (!found) {
printk("LSM module %s was not found\n", name);
}
}
list_for_each_entry_safe(ops, tmp, &lsm_hooks[lsm_candidate]) {
list_del(&ops->list[lsm_candidate]);
printk("LSM module %s was not enabled\n", ops->name);
}
}
security_initcall(register_lsms);
(Well, list_add_tail() in pure_initcall functions should be optimized
by statically embedding into security/security.c at compile time?)
On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> On 4/24/2013 4:00 PM, John Johansen wrote:
> > On 04/24/2013 02:15 PM, Paul Moore wrote:
> >> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
...
> >>> An interesting aside that may be relevant is that the error
> >>> condition behavior makes it advisable to have the LSM you care
> >>> about most go last. If the networking components were strictly
> >>> FCFS you might have to chose an ordering you might not want for
> >>> other reasons.
> >>
> >> Well, maybe not ... I think. If we take a FCFS approach to the network
> >> controls then only one LSM is really ever going to throw an error on the
> >> network hooks, yes?
>
> You set up the order you want to get the networking handled
> correctly and you could get filesystem hooks in the wrong order.
> Not that that really ought to be a problem, but there are wonky
> admin tools out there.
I don't quite follow; can you be a bit more explicit about getting the
filesystem hooks in the wrong order?
> >> I'm still in favor of assigning the network hooks to the LSM at boot
> >> based on the "security=" configuration.
> >
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
>
> I'll have a go at it then. What that would mean is that:
>
> security=smack,selinux
>
> gives Smack NetLabel and SELinux xfrm and secmark while
>
> security=selinux,smack
>
> gives SELinux all three.
That seems reasonable, it also keeps the door open for adding a specific
network hook ordering option, e.g. "security_net=", at a later date if
necessary.
> I would still like it to be possible to explicitly configure the allocation
> at build time.
I suppose I have no object to that, I would just place my vote to have the
dynamic FCFS (or LCFS if that makes more sense) assignment be the Kconfig
default.
--
paul moore
http://www.paul-moore.com
On 4/25/2013 8:01 AM, Paul Moore wrote:
> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
>> On 4/24/2013 4:00 PM, John Johansen wrote:
>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
>>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
> ...
>
>>>>> An interesting aside that may be relevant is that the error
>>>>> condition behavior makes it advisable to have the LSM you care
>>>>> about most go last. If the networking components were strictly
>>>>> FCFS you might have to chose an ordering you might not want for
>>>>> other reasons.
>>>> Well, maybe not ... I think. If we take a FCFS approach to the network
>>>> controls then only one LSM is really ever going to throw an error on the
>>>> network hooks, yes?
>> You set up the order you want to get the networking handled
>> correctly and you could get filesystem hooks in the wrong order.
>> Not that that really ought to be a problem, but there are wonky
>> admin tools out there.
> I don't quite follow; can you be a bit more explicit about getting the
> filesystem hooks in the wrong order?
Let's assume that there's a case for the stat() system call that
would get EPERM from SELinux and EACCES from Smack. A carefully
crafted admin tool might take different actions based on the return
code. If Smack ahead of SELinux in the list the tool will respond
one way, whereas if SELinux is ahead it will behave the other way.
If this tool came with Fedora it will likely expect the SELinux
error code. Thus, it will be somewhat important that Smack precede
SELinux in the LSM ordering. That will grant Smack the NetLabel
component. If you want SELinux to use NetLabel you'll have to
explicitly configure that.
It's probably not going to be an issue that often. Making the
ordering implications clear to those who may be affected by them
is probably the best choice and biggest challenge. It would be
nice to keep them to a minimum. I fear some future LSM author
getting clever with error codes and demanding the ultimate
position in all cases.
>>>> I'm still in favor of assigning the network hooks to the LSM at boot
>>>> based on the "security=" configuration.
>>> yeah dealing with selection at boot time is going to be needed
>>> at some point, whether its now or later ...
>> I'll have a go at it then. What that would mean is that:
>>
>> security=smack,selinux
>>
>> gives Smack NetLabel and SELinux xfrm and secmark while
>>
>> security=selinux,smack
>>
>> gives SELinux all three.
> That seems reasonable, it also keeps the door open for adding a specific
> network hook ordering option, e.g. "security_net=", at a later date if
> necessary.
>
>> I would still like it to be possible to explicitly configure the allocation
>> at build time.
> I suppose I have no object to that, I would just place my vote to have the
> dynamic FCFS (or LCFS if that makes more sense) assignment be the Kconfig
> default.
>
On Thursday, April 25, 2013 11:09:23 AM Casey Schaufler wrote:
> On 4/25/2013 8:01 AM, Paul Moore wrote:
> > On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> >> On 4/24/2013 4:00 PM, John Johansen wrote:
> >>> On 04/24/2013 02:15 PM, Paul Moore wrote:
> >>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
> > ...
> >
> >>>>> An interesting aside that may be relevant is that the error
> >>>>> condition behavior makes it advisable to have the LSM you care
> >>>>> about most go last. If the networking components were strictly
> >>>>> FCFS you might have to chose an ordering you might not want for
> >>>>> other reasons.
> >>>>
> >>>> Well, maybe not ... I think. If we take a FCFS approach to the network
> >>>> controls then only one LSM is really ever going to throw an error on
> >>>> the
> >>>> network hooks, yes?
> >>
> >> You set up the order you want to get the networking handled
> >> correctly and you could get filesystem hooks in the wrong order.
> >> Not that that really ought to be a problem, but there are wonky
> >> admin tools out there.
> >
> > I don't quite follow; can you be a bit more explicit about getting the
> > filesystem hooks in the wrong order?
>
> Let's assume that there's a case for the stat() system call that
> would get EPERM from SELinux and EACCES from Smack. A carefully
> crafted admin tool might take different actions based on the return
> code. If Smack ahead of SELinux in the list the tool will respond
> one way, whereas if SELinux is ahead it will behave the other way.
>
> If this tool came with Fedora it will likely expect the SELinux
> error code. Thus, it will be somewhat important that Smack precede
> SELinux in the LSM ordering. That will grant Smack the NetLabel
> component. If you want SELinux to use NetLabel you'll have to
> explicitly configure that.
>
> It's probably not going to be an issue that often. Making the
> ordering implications clear to those who may be affected by them
> is probably the best choice and biggest challenge. It would be
> nice to keep them to a minimum. I fear some future LSM author
> getting clever with error codes and demanding the ultimate
> position in all cases.
I guess this begs the question, why does the stacking take the return value
from the last LSM and not the first? I'm sure there was a design decision
made here, I'm just curious about the reasons why.
To me, and maybe I'm the odd one out here, but I would think that the first
LSM in the stacking order should get precedence; this is why I'm pushing for a
FCFS for the network controls. If it turns out that the stacking patches give
preference for the last LSM in the stacking order (I think this will always
seem backwards to me) then we should probably give the networking controls to
the last LSM.
--
paul moore
http://www.paul-moore.com
On 4/25/2013 12:14 PM, Paul Moore wrote:
> On Thursday, April 25, 2013 11:09:23 AM Casey Schaufler wrote:
>> On 4/25/2013 8:01 AM, Paul Moore wrote:
>>> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
>>>> On 4/24/2013 4:00 PM, John Johansen wrote:
>>>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
>>>>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>>> ...
>>>
>>>>>>> An interesting aside that may be relevant is that the error
>>>>>>> condition behavior makes it advisable to have the LSM you care
>>>>>>> about most go last. If the networking components were strictly
>>>>>>> FCFS you might have to chose an ordering you might not want for
>>>>>>> other reasons.
>>>>>> Well, maybe not ... I think. If we take a FCFS approach to the network
>>>>>> controls then only one LSM is really ever going to throw an error on
>>>>>> the
>>>>>> network hooks, yes?
>>>> You set up the order you want to get the networking handled
>>>> correctly and you could get filesystem hooks in the wrong order.
>>>> Not that that really ought to be a problem, but there are wonky
>>>> admin tools out there.
>>> I don't quite follow; can you be a bit more explicit about getting the
>>> filesystem hooks in the wrong order?
>> Let's assume that there's a case for the stat() system call that
>> would get EPERM from SELinux and EACCES from Smack. A carefully
>> crafted admin tool might take different actions based on the return
>> code. If Smack ahead of SELinux in the list the tool will respond
>> one way, whereas if SELinux is ahead it will behave the other way.
>>
>> If this tool came with Fedora it will likely expect the SELinux
>> error code. Thus, it will be somewhat important that Smack precede
>> SELinux in the LSM ordering. That will grant Smack the NetLabel
>> component. If you want SELinux to use NetLabel you'll have to
>> explicitly configure that.
>>
>> It's probably not going to be an issue that often. Making the
>> ordering implications clear to those who may be affected by them
>> is probably the best choice and biggest challenge. It would be
>> nice to keep them to a minimum. I fear some future LSM author
>> getting clever with error codes and demanding the ultimate
>> position in all cases.
> I guess this begs the question, why does the stacking take the return value
> from the last LSM and not the first? I'm sure there was a design decision
> made here, I'm just curious about the reasons why.
The hook loop is trivially simpler if you return the last error than
if you return the first error:
if (thisrc)
rc = thisrc;
vs
if (thisrc && !rc)
rc = thisrc;
If I had decided to do shortcutting (return on first failure) it
would be a different story.
> To me, and maybe I'm the odd one out here,
I don't know that you're the only odd one here. :)
> but I would think that the first
> LSM in the stacking order should get precedence;
My desire and intent is that to the extent possible there should
be no "principle" LSM. The choice of last error is purely driven
by the fact that it's the easiest thing to do.
> this is why I'm pushing for a
> FCFS for the network controls. If it turns out that the stacking patches give
> preference for the last LSM in the stacking order (I think this will always
> seem backwards to me) then we should probably give the networking controls to
> the last LSM.
I actually think that FCFS for networking services and last error code
hits closest to the sweet spot. "security=yama,smack,selinux" would give
NetLabel to Smack and xfrm and secmark to SELinux. It would also give
SELinux error returns in cases where there are multiple reasons for
denial. Since SELinux has a more sophisticated runtime environment than
Smack this is likely to make Fedora (for example) happier.
On Thu, Apr 25, 2013 at 1:21 PM, Casey Schaufler <[email protected]> wrote:
> On 4/25/2013 12:14 PM, Paul Moore wrote:
>> On Thursday, April 25, 2013 11:09:23 AM Casey Schaufler wrote:
>>> On 4/25/2013 8:01 AM, Paul Moore wrote:
>>>> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
>>>>> On 4/24/2013 4:00 PM, John Johansen wrote:
>>>>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
>>>>>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>>>> ...
>>>>
>>>>>>>> An interesting aside that may be relevant is that the error
>>>>>>>> condition behavior makes it advisable to have the LSM you care
>>>>>>>> about most go last. If the networking components were strictly
>>>>>>>> FCFS you might have to chose an ordering you might not want for
>>>>>>>> other reasons.
>>>>>>> Well, maybe not ... I think. If we take a FCFS approach to the network
>>>>>>> controls then only one LSM is really ever going to throw an error on
>>>>>>> the
>>>>>>> network hooks, yes?
>>>>> You set up the order you want to get the networking handled
>>>>> correctly and you could get filesystem hooks in the wrong order.
>>>>> Not that that really ought to be a problem, but there are wonky
>>>>> admin tools out there.
>>>> I don't quite follow; can you be a bit more explicit about getting the
>>>> filesystem hooks in the wrong order?
>>> Let's assume that there's a case for the stat() system call that
>>> would get EPERM from SELinux and EACCES from Smack. A carefully
>>> crafted admin tool might take different actions based on the return
>>> code. If Smack ahead of SELinux in the list the tool will respond
>>> one way, whereas if SELinux is ahead it will behave the other way.
>>>
>>> If this tool came with Fedora it will likely expect the SELinux
>>> error code. Thus, it will be somewhat important that Smack precede
>>> SELinux in the LSM ordering. That will grant Smack the NetLabel
>>> component. If you want SELinux to use NetLabel you'll have to
>>> explicitly configure that.
>>>
>>> It's probably not going to be an issue that often. Making the
>>> ordering implications clear to those who may be affected by them
>>> is probably the best choice and biggest challenge. It would be
>>> nice to keep them to a minimum. I fear some future LSM author
>>> getting clever with error codes and demanding the ultimate
>>> position in all cases.
>> I guess this begs the question, why does the stacking take the return value
>> from the last LSM and not the first? I'm sure there was a design decision
>> made here, I'm just curious about the reasons why.
>
> The hook loop is trivially simpler if you return the last error than
> if you return the first error:
>
> if (thisrc)
> rc = thisrc;
>
> vs
>
> if (thisrc && !rc)
> rc = thisrc;
>
> If I had decided to do shortcutting (return on first failure) it
> would be a different story.
>
>> To me, and maybe I'm the odd one out here,
>
> I don't know that you're the only odd one here. :)
>
>> but I would think that the first
>> LSM in the stacking order should get precedence;
>
> My desire and intent is that to the extent possible there should
> be no "principle" LSM. The choice of last error is purely driven
> by the fact that it's the easiest thing to do.
>
>> this is why I'm pushing for a
>> FCFS for the network controls. If it turns out that the stacking patches give
>> preference for the last LSM in the stacking order (I think this will always
>> seem backwards to me) then we should probably give the networking controls to
>> the last LSM.
>
> I actually think that FCFS for networking services and last error code
> hits closest to the sweet spot. "security=yama,smack,selinux" would give
> NetLabel to Smack and xfrm and secmark to SELinux. It would also give
> SELinux error returns in cases where there are multiple reasons for
> denial. Since SELinux has a more sophisticated runtime environment than
> Smack this is likely to make Fedora (for example) happier.
Yeah, this seems good to me too.
-Kees
--
Kees Cook
Chrome OS Security
On Thursday, April 25, 2013 01:21:50 PM Casey Schaufler wrote:
> On 4/25/2013 12:14 PM, Paul Moore wrote:
> > On Thursday, April 25, 2013 11:09:23 AM Casey Schaufler wrote:
> >> On 4/25/2013 8:01 AM, Paul Moore wrote:
> >>> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> >>>> On 4/24/2013 4:00 PM, John Johansen wrote:
> >>>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
> >>>>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
> >>> ...
> >>>
> >>>>>>> An interesting aside that may be relevant is that the error
> >>>>>>> condition behavior makes it advisable to have the LSM you care
> >>>>>>> about most go last. If the networking components were strictly
> >>>>>>> FCFS you might have to chose an ordering you might not want for
> >>>>>>> other reasons.
> >>>>>>
> >>>>>> Well, maybe not ... I think. If we take a FCFS approach to the
> >>>>>> network
> >>>>>> controls then only one LSM is really ever going to throw an error on
> >>>>>> the
> >>>>>> network hooks, yes?
> >>>>
> >>>> You set up the order you want to get the networking handled
> >>>> correctly and you could get filesystem hooks in the wrong order.
> >>>> Not that that really ought to be a problem, but there are wonky
> >>>> admin tools out there.
> >>>
> >>> I don't quite follow; can you be a bit more explicit about getting the
> >>> filesystem hooks in the wrong order?
> >>
> >> Let's assume that there's a case for the stat() system call that
> >> would get EPERM from SELinux and EACCES from Smack. A carefully
> >> crafted admin tool might take different actions based on the return
> >> code. If Smack ahead of SELinux in the list the tool will respond
> >> one way, whereas if SELinux is ahead it will behave the other way.
> >>
> >> If this tool came with Fedora it will likely expect the SELinux
> >> error code. Thus, it will be somewhat important that Smack precede
> >> SELinux in the LSM ordering. That will grant Smack the NetLabel
> >> component. If you want SELinux to use NetLabel you'll have to
> >> explicitly configure that.
> >>
> >> It's probably not going to be an issue that often. Making the
> >> ordering implications clear to those who may be affected by them
> >> is probably the best choice and biggest challenge. It would be
> >> nice to keep them to a minimum. I fear some future LSM author
> >> getting clever with error codes and demanding the ultimate
> >> position in all cases.
> >
> > I guess this begs the question, why does the stacking take the return
> > value
> > from the last LSM and not the first? I'm sure there was a design decision
> > made here, I'm just curious about the reasons why.
>
> The hook loop is trivially simpler if you return the last error than
> if you return the first error:
>
> if (thisrc)
> rc = thisrc;
>
> vs
>
> if (thisrc && !rc)
> rc = thisrc;
>
> If I had decided to do shortcutting (return on first failure) it
> would be a different story.
Okay, fair enough. Thanks.
> > To me, and maybe I'm the odd one out here,
>
> I don't know that you're the only odd one here. :)
>
> > but I would think that the first LSM in the stacking order should get
> > precedence;
>
> My desire and intent is that to the extent possible there should
> be no "principle" LSM. The choice of last error is purely driven
> by the fact that it's the easiest thing to do.
I'm not sure if you can call it a "principle" LSM or not, but as long as we've
got portions of the kernel that don't support LSM stacked, e.g. the network
stack, we're always going to have one LSM that has a bit more control than
others.
> > this is why I'm pushing for a FCFS for the network controls. If it turns
> > out that the stacking patches give preference for the last LSM in the
> > stacking order (I think this will always seem backwards to me) then we
> > should probably give the networking controls to the last LSM.
>
> I actually think that FCFS for networking services and last error code
> hits closest to the sweet spot. "security=yama,smack,selinux" would give
> NetLabel to Smack and xfrm and secmark to SELinux. It would also give
> SELinux error returns in cases where there are multiple reasons for
> denial. Since SELinux has a more sophisticated runtime environment than
> Smack this is likely to make Fedora (for example) happier.
Okay, works for me. The thing I'm most concerned about is just making sure we
make the network bits a boot time configuration and not just a compile time
option.
--
paul moore
http://www.paul-moore.com