| Message ID | 20170714164647.6183-1-sds@tycho.nsa.gov (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > As systemd ramps up enabling NNP (NoNewPrivileges) for system services, > it is increasingly breaking SELinux domain transitions for those services > and their descendants. systemd enables NNP not only for services whose > unit files explicitly specify NoNewPrivileges=yes but also for services > whose unit files specify any of the following options in combination with > running without CAP_SYS_ADMIN (e.g. specifying User= or a > CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, > SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, > MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5) > man page. > > The end result is bad for the security of both SELinux-disabled and > SELinux-enabled systems. Packagers have to turn off these > options in the unit files to preserve SELinux domain transitions. For > users who choose to disable SELinux, this means that they miss out on > at least having the systemd-supported protections. For users who keep > SELinux enabled, they may still be missing out on some protections > because it isn't necessarily guaranteed that the SELinux policy for > that service provides the same protections in all cases. > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in > order to support limited usage for sandboxing programs. However, > defining typebounds for all of the affected service domains > is impractical to implement in policy, since typebounds requires us > to ensure that each domain is allowed everything all of its descendant > domains are allowed, and this has to be repeated for the entire chain > of domain transitions. There is no way to clone all allow rules from > descendants to their ancestors in policy currently, and doing so would > be undesirable even if it were practical, as it requires leaking > permissions to objects and operations into ancestor domains that could > weaken their own security in order to allow them to the descendants > (e.g. if a descendant requires execmem permission, then so do all of > its ancestors; if a descendant requires execute permission to a file, > then so do all of its ancestors; if a descendant requires read to a > symbolic link or temporary file, then so do all of its ancestors...). > SELinux domains are intentionally not hierarchical / bounded in this > manner normally, and making them so would undermine their protections > and least privilege. > > We have long had a similar tension with SELinux transitions and nosuid > mounts, albeit not as severe. Users often have had to choose between > retaining nosuid on a mount and allowing SELinux domain transitions on > files within those mounts. This likewise leads to unfortunate tradeoffs > in security. > > Decouple NNP/nosuid from SELinux transitions, so that we don't have to > make a choice between them. Introduce a nnp_nosuid_transition policy > capability that causes the ability to transition under NNP/nosuid to > be based on a nnp_nosuid_transition permission between the old and new > contexts rather than typebounds. Domain transitions can then be allowed > in policy without requiring the parent to be a strict superset of all of > its children. > > With this change, systemd unit files can be left unmodified from upstream. > SELinux-disabled and SELinux-enabled users will benefit from retaining any > of the systemd-provided protections. SELinux policy will only need to > be adapted to enable the new policy capability and to allow the > new permission between domain pairs as appropriate. > I'm okay with this, so long as it's very clearly documented that, if you allow the new transition type from domain A to B, you should assume that domain A can compromise domain B. If I get a bug report complaining that seccomp or whatever allowed compromising a magic nnp child domain, I will say "no, that's not a bug". --Andy
On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote: > As systemd ramps up enabling NNP (NoNewPrivileges) for system services, > it is increasingly breaking SELinux domain transitions for those services > and their descendants. systemd enables NNP not only for services whose > unit files explicitly specify NoNewPrivileges=yes but also for services > whose unit files specify any of the following options in combination with > running without CAP_SYS_ADMIN (e.g. specifying User= or a > CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, > SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, > MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5) > man page. > > The end result is bad for the security of both SELinux-disabled and > SELinux-enabled systems. Packagers have to turn off these > options in the unit files to preserve SELinux domain transitions. For > users who choose to disable SELinux, this means that they miss out on > at least having the systemd-supported protections. For users who keep > SELinux enabled, they may still be missing out on some protections > because it isn't necessarily guaranteed that the SELinux policy for > that service provides the same protections in all cases. > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in > order to support limited usage for sandboxing programs. However, > defining typebounds for all of the affected service domains > is impractical to implement in policy, since typebounds requires us > to ensure that each domain is allowed everything all of its descendant > domains are allowed, and this has to be repeated for the entire chain > of domain transitions. There is no way to clone all allow rules from > descendants to their ancestors in policy currently, and doing so would > be undesirable even if it were practical, as it requires leaking > permissions to objects and operations into ancestor domains that could > weaken their own security in order to allow them to the descendants > (e.g. if a descendant requires execmem permission, then so do all of > its ancestors; if a descendant requires execute permission to a file, > then so do all of its ancestors; if a descendant requires read to a > symbolic link or temporary file, then so do all of its ancestors...). > SELinux domains are intentionally not hierarchical / bounded in this > manner normally, and making them so would undermine their protections > and least privilege. > > We have long had a similar tension with SELinux transitions and nosuid > mounts, albeit not as severe. Users often have had to choose between > retaining nosuid on a mount and allowing SELinux domain transitions on > files within those mounts. This likewise leads to unfortunate tradeoffs > in security. > > Decouple NNP/nosuid from SELinux transitions, so that we don't have to > make a choice between them. Introduce a nnp_nosuid_transition policy > capability that causes the ability to transition under NNP/nosuid to > be based on a nnp_nosuid_transition permission between the old and new > contexts rather than typebounds. Domain transitions can then be allowed > in policy without requiring the parent to be a strict superset of all of > its children. > > With this change, systemd unit files can be left unmodified from upstream. > SELinux-disabled and SELinux-enabled users will benefit from retaining any > of the systemd-provided protections. SELinux policy will only need to > be adapted to enable the new policy capability and to allow the > new permission between domain pairs as appropriate. > A few things, the name is pretty awkward. my main issue with it is what if some other similar kind of thing is added in the future then we'll have nnp_nosuid_transition that should also cover it but the name wont cover it. Why do we want to disallow type-bounds to work even with the capability? it seems sensible to me to allow typebounds to transition even in the future. If we do then we probably dont need the policycap which seems less complicated. also how are we thinking to do this in refpol? only add it specifically as needed? or would it be added to the execute_file_perms type macros? Although, grep typebounds is nowhere to be found currently in either refpol and gentoo's repo. -- Jason > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> > --- > security/selinux/hooks.c | 41 ++++++++++++++++++++++++------------- > security/selinux/include/classmap.h | 2 +- > security/selinux/include/security.h | 2 ++ > security/selinux/ss/services.c | 7 ++++++- > 4 files changed, 36 insertions(+), 16 deletions(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 3a06afb..932b72d 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm, > return 0; /* No change in credentials */ > > /* > - * The only transitions we permit under NNP or nosuid > - * are transitions to bounded SIDs, i.e. SIDs that are > - * guaranteed to only be allowed a subset of the permissions > - * of the current SID. > + * If the policy enables the nnp_nosuid_transition policy capability, > + * then we permit transitions under NNP or nosuid if the > + * policy explicitly allows nnp_nosuid_transition permission between > + * the old and new contexts. > */ > - rc = security_bounded_transition(old_tsec->sid, new_tsec->sid); > - if (rc) { > + if (selinux_policycap_nnp_nosuid_transition) { > + rc = avc_has_perm(old_tsec->sid, new_tsec->sid, > + SECCLASS_PROCESS, > + PROCESS__NNP_NOSUID_TRANSITION, NULL); > + if (!rc) > + return 0; > + } else { > /* > - * On failure, preserve the errno values for NNP vs nosuid. > - * NNP: Operation not permitted for caller. > - * nosuid: Permission denied to file. > + * Otherwise, the only transitions we permit under NNP or nosuid > + * are transitions to bounded SIDs, i.e. SIDs that are > + * guaranteed to only be allowed a subset of the permissions > + * of the current SID. > */ > - if (nnp) > - return -EPERM; > - else > - return -EACCES; > + rc = security_bounded_transition(old_tsec->sid, new_tsec->sid); > + if (!rc) > + return 0; > } > - return 0; > + > + /* > + * On failure, preserve the errno values for NNP vs nosuid. > + * NNP: Operation not permitted for caller. > + * nosuid: Permission denied to file. > + */ > + if (nnp) > + return -EPERM; > + return -EACCES; > } > > static int selinux_bprm_set_creds(struct linux_binprm *bprm) > diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h > index b9fe343..dff81b8 100644 > --- a/security/selinux/include/classmap.h > +++ b/security/selinux/include/classmap.h > @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = { > "getattr", "setexec", "setfscreate", "noatsecure", "siginh", > "setrlimit", "rlimitinh", "dyntransition", "setcurrent", > "execmem", "execstack", "execheap", "setkeycreate", > - "setsockcreate", "getrlimit", NULL } }, > + "setsockcreate", "getrlimit", "nnp_nosuid_transition", NULL } }, > { "system", > { "ipc_info", "syslog_read", "syslog_mod", > "syslog_console", "module_request", "module_load", NULL } }, > diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h > index e91f08c..3e32317 100644 > --- a/security/selinux/include/security.h > +++ b/security/selinux/include/security.h > @@ -73,6 +73,7 @@ enum { > POLICYDB_CAPABILITY_EXTSOCKCLASS, > POLICYDB_CAPABILITY_ALWAYSNETWORK, > POLICYDB_CAPABILITY_CGROUPSECLABEL, > + POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION, > __POLICYDB_CAPABILITY_MAX > }; > #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1) > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm; > extern int selinux_policycap_extsockclass; > extern int selinux_policycap_alwaysnetwork; > extern int selinux_policycap_cgroupseclabel; > +extern int selinux_policycap_nnp_nosuid_transition; > > /* > * type_datum properties > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c > index 2f02fa6..16c55de 100644 > --- a/security/selinux/ss/services.c > +++ b/security/selinux/ss/services.c > @@ -76,7 +76,8 @@ char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = { > "open_perms", > "extended_socket_class", > "always_check_network", > - "cgroup_seclabel" > + "cgroup_seclabel", > + "nnp_nosuid_transition" > }; > > int selinux_policycap_netpeer; > @@ -84,6 +85,7 @@ int selinux_policycap_openperm; > int selinux_policycap_extsockclass; > int selinux_policycap_alwaysnetwork; > int selinux_policycap_cgroupseclabel; > +int selinux_policycap_nnp_nosuid_transition; > > static DEFINE_RWLOCK(policy_rwlock); > > @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void) > selinux_policycap_cgroupseclabel = > ebitmap_get_bit(&policydb.policycaps, > POLICYDB_CAPABILITY_CGROUPSECLABEL); > + selinux_policycap_nnp_nosuid_transition = > + ebitmap_get_bit(&policydb.policycaps, > + POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION); > > for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++) > pr_info("SELinux: policy capability %s=%d\n", > -- > 2.9.4 >
On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> wrote: > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote: >> As systemd ramps up enabling NNP (NoNewPrivileges) for system services, >> it is increasingly breaking SELinux domain transitions for those services >> and their descendants. systemd enables NNP not only for services whose >> unit files explicitly specify NoNewPrivileges=yes but also for services >> whose unit files specify any of the following options in combination with >> running without CAP_SYS_ADMIN (e.g. specifying User= or a >> CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, >> SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, >> PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, >> MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5) >> man page. >> >> The end result is bad for the security of both SELinux-disabled and >> SELinux-enabled systems. Packagers have to turn off these >> options in the unit files to preserve SELinux domain transitions. For >> users who choose to disable SELinux, this means that they miss out on >> at least having the systemd-supported protections. For users who keep >> SELinux enabled, they may still be missing out on some protections >> because it isn't necessarily guaranteed that the SELinux policy for >> that service provides the same protections in all cases. >> >> commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under >> NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in >> order to support limited usage for sandboxing programs. However, >> defining typebounds for all of the affected service domains >> is impractical to implement in policy, since typebounds requires us >> to ensure that each domain is allowed everything all of its descendant >> domains are allowed, and this has to be repeated for the entire chain >> of domain transitions. There is no way to clone all allow rules from >> descendants to their ancestors in policy currently, and doing so would >> be undesirable even if it were practical, as it requires leaking >> permissions to objects and operations into ancestor domains that could >> weaken their own security in order to allow them to the descendants >> (e.g. if a descendant requires execmem permission, then so do all of >> its ancestors; if a descendant requires execute permission to a file, >> then so do all of its ancestors; if a descendant requires read to a >> symbolic link or temporary file, then so do all of its ancestors...). >> SELinux domains are intentionally not hierarchical / bounded in this >> manner normally, and making them so would undermine their protections >> and least privilege. >> >> We have long had a similar tension with SELinux transitions and nosuid >> mounts, albeit not as severe. Users often have had to choose between >> retaining nosuid on a mount and allowing SELinux domain transitions on >> files within those mounts. This likewise leads to unfortunate tradeoffs >> in security. >> >> Decouple NNP/nosuid from SELinux transitions, so that we don't have to >> make a choice between them. Introduce a nnp_nosuid_transition policy >> capability that causes the ability to transition under NNP/nosuid to >> be based on a nnp_nosuid_transition permission between the old and new >> contexts rather than typebounds. Domain transitions can then be allowed >> in policy without requiring the parent to be a strict superset of all of >> its children. >> >> With this change, systemd unit files can be left unmodified from upstream. >> SELinux-disabled and SELinux-enabled users will benefit from retaining any >> of the systemd-provided protections. SELinux policy will only need to >> be adapted to enable the new policy capability and to allow the >> new permission between domain pairs as appropriate. > > A few things, the name is pretty awkward. my main issue with it is what > if some other similar kind of thing is added in the future then we'll > have nnp_nosuid_transition that should also cover it but the name wont > cover it. Yes, I don't think anyone is in love with the name, but no one offered anything better; see the previous patch posting for some of that discussion. If you have a better suggestion I would love to hear it. > Why do we want to disallow type-bounds to work even with the capability? > it seems sensible to me to allow typebounds to transition even in the > future. If we do then we probably dont need the policycap which seems > less complicated. The suggestion to continue to support bounded domain transitions seems reasonable to me, although we would need to worry about which check to do first (bounded transition or process:nnp_nosuid_transition), and how to limit the auditing/reporting so admins are confused by the first check failing, yet the transition still taking place. None of these are unsolvable problems, but it will likely need a bit more work. I'm sure Stephen has some thoughts on this as well. > also how are we thinking to do this in refpol? only add it specifically > as needed? or would it be added to the execute_file_perms type macros? > Although, grep typebounds is nowhere to be found currently in either > refpol and gentoo's repo. I'm *really* hoping this new permission is only granted where absolutely needed, which I hope should be rather small (see the patch description and the discussion regarding systemd unit files).
On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> > wrote: > > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote: > > > As systemd ramps up enabling NNP (NoNewPrivileges) for system > > > services, > > > it is increasingly breaking SELinux domain transitions for those > > > services > > > and their descendants. systemd enables NNP not only for services > > > whose > > > unit files explicitly specify NoNewPrivileges=yes but also for > > > services > > > whose unit files specify any of the following options in > > > combination with > > > running without CAP_SYS_ADMIN (e.g. specifying User= or a > > > CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, > > > SystemCallArchitectures=, RestrictAddressFamilies=, > > > RestrictNamespaces=, > > > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, > > > MemoryDenyWriteExecute=, or RestrictRealtime= as per the > > > systemd.exec(5) > > > man page. > > > > > > The end result is bad for the security of both SELinux-disabled > > > and > > > SELinux-enabled systems. Packagers have to turn off these > > > options in the unit files to preserve SELinux domain > > > transitions. For > > > users who choose to disable SELinux, this means that they miss > > > out on > > > at least having the systemd-supported protections. For users who > > > keep > > > SELinux enabled, they may still be missing out on some > > > protections > > > because it isn't necessarily guaranteed that the SELinux policy > > > for > > > that service provides the same protections in all cases. > > > > > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under > > > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP > > > in > > > order to support limited usage for sandboxing programs. However, > > > defining typebounds for all of the affected service domains > > > is impractical to implement in policy, since typebounds requires > > > us > > > to ensure that each domain is allowed everything all of its > > > descendant > > > domains are allowed, and this has to be repeated for the entire > > > chain > > > of domain transitions. There is no way to clone all allow rules > > > from > > > descendants to their ancestors in policy currently, and doing so > > > would > > > be undesirable even if it were practical, as it requires leaking > > > permissions to objects and operations into ancestor domains that > > > could > > > weaken their own security in order to allow them to the > > > descendants > > > (e.g. if a descendant requires execmem permission, then so do all > > > of > > > its ancestors; if a descendant requires execute permission to a > > > file, > > > then so do all of its ancestors; if a descendant requires read to > > > a > > > symbolic link or temporary file, then so do all of its > > > ancestors...). > > > SELinux domains are intentionally not hierarchical / bounded in > > > this > > > manner normally, and making them so would undermine their > > > protections > > > and least privilege. > > > > > > We have long had a similar tension with SELinux transitions and > > > nosuid > > > mounts, albeit not as severe. Users often have had to choose > > > between > > > retaining nosuid on a mount and allowing SELinux domain > > > transitions on > > > files within those mounts. This likewise leads to unfortunate > > > tradeoffs > > > in security. > > > > > > Decouple NNP/nosuid from SELinux transitions, so that we don't > > > have to > > > make a choice between them. Introduce a nnp_nosuid_transition > > > policy > > > capability that causes the ability to transition under NNP/nosuid > > > to > > > be based on a nnp_nosuid_transition permission between the old > > > and new > > > contexts rather than typebounds. Domain transitions can then be > > > allowed > > > in policy without requiring the parent to be a strict superset of > > > all of > > > its children. > > > > > > With this change, systemd unit files can be left unmodified from > > > upstream. > > > SELinux-disabled and SELinux-enabled users will benefit from > > > retaining any > > > of the systemd-provided protections. SELinux policy will only > > > need to > > > be adapted to enable the new policy capability and to allow the > > > new permission between domain pairs as appropriate. > > > > A few things, the name is pretty awkward. my main issue with it is > > what > > if some other similar kind of thing is added in the future then > > we'll > > have nnp_nosuid_transition that should also cover it but the name > > wont > > cover it. > > Yes, I don't think anyone is in love with the name, but no one > offered > anything better; see the previous patch posting for some of that > discussion. If you have a better suggestion I would love to hear it. Agreed, although I'm skeptical that there will be any "other similar kind of thing" added in the future that we would want to cover under the same permission. > > > Why do we want to disallow type-bounds to work even with the > > capability? > > it seems sensible to me to allow typebounds to transition even in > > the > > future. If we do then we probably dont need the policycap which > > seems > > less complicated. > > The suggestion to continue to support bounded domain transitions > seems > reasonable to me, although we would need to worry about which check > to > do first (bounded transition or process:nnp_nosuid_transition), and > how to limit the auditing/reporting so admins are confused by the > first check failing, yet the transition still taking place. None of > these are unsolvable problems, but it will likely need a bit more > work. > > I'm sure Stephen has some thoughts on this as well. Others (e.g. Dominick) seemed to take the opposite view on the earlier RFC discussion, i.e. that we should only check the new permission if the capability is enabled. I specifically raised that as a question there. I'm willing to change it to fallback to checking for a bounded type, but that will mean two audit messages (I don't think we can just hide one of them) when neither is allowed. That said, it is unlikely to cause much confusion in practice because users typically only look for and pay attention to AVC messages, and anyone using audit2allow will just end up allowing the permission, not the bounds. > > > also how are we thinking to do this in refpol? only add it > > specifically > > as needed? or would it be added to the execute_file_perms type > > macros? > > Although, grep typebounds is nowhere to be found currently in > > either > > refpol and gentoo's repo. > > I'm *really* hoping this new permission is only granted where > absolutely needed, which I hope should be rather small (see the patch > description and the discussion regarding systemd unit files). Actually, I'm not clear on that. If systemd continues to expand the usage of these options in its unit files (which seems likely), then I could see this ultimately affecting all service domains and all of their descendants. If it was only going to be a handful of domains, then the typebounds solution might be more tractable, albeit painful.
On Tue, Jul 18, 2017 at 09:17:58AM -0400, Stephen Smalley wrote: > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> > > wrote: > > > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote: > > > > As systemd ramps up enabling NNP (NoNewPrivileges) for system > > > > services, > > > > it is increasingly breaking SELinux domain transitions for those > > > > services > > > > and their descendants. systemd enables NNP not only for services > > > > whose > > > > unit files explicitly specify NoNewPrivileges=yes but also for > > > > services > > > > whose unit files specify any of the following options in > > > > combination with > > > > running without CAP_SYS_ADMIN (e.g. specifying User= or a > > > > CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, > > > > SystemCallArchitectures=, RestrictAddressFamilies=, > > > > RestrictNamespaces=, > > > > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, > > > > MemoryDenyWriteExecute=, or RestrictRealtime= as per the > > > > systemd.exec(5) > > > > man page. > > > > > > > > The end result is bad for the security of both SELinux-disabled > > > > and > > > > SELinux-enabled systems. Packagers have to turn off these > > > > options in the unit files to preserve SELinux domain > > > > transitions. For > > > > users who choose to disable SELinux, this means that they miss > > > > out on > > > > at least having the systemd-supported protections. For users who > > > > keep > > > > SELinux enabled, they may still be missing out on some > > > > protections > > > > because it isn't necessarily guaranteed that the SELinux policy > > > > for > > > > that service provides the same protections in all cases. > > > > > > > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under > > > > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP > > > > in > > > > order to support limited usage for sandboxing programs. However, > > > > defining typebounds for all of the affected service domains > > > > is impractical to implement in policy, since typebounds requires > > > > us > > > > to ensure that each domain is allowed everything all of its > > > > descendant > > > > domains are allowed, and this has to be repeated for the entire > > > > chain > > > > of domain transitions. There is no way to clone all allow rules > > > > from > > > > descendants to their ancestors in policy currently, and doing so > > > > would > > > > be undesirable even if it were practical, as it requires leaking > > > > permissions to objects and operations into ancestor domains that > > > > could > > > > weaken their own security in order to allow them to the > > > > descendants > > > > (e.g. if a descendant requires execmem permission, then so do all > > > > of > > > > its ancestors; if a descendant requires execute permission to a > > > > file, > > > > then so do all of its ancestors; if a descendant requires read to > > > > a > > > > symbolic link or temporary file, then so do all of its > > > > ancestors...). > > > > SELinux domains are intentionally not hierarchical / bounded in > > > > this > > > > manner normally, and making them so would undermine their > > > > protections > > > > and least privilege. > > > > > > > > We have long had a similar tension with SELinux transitions and > > > > nosuid > > > > mounts, albeit not as severe. Users often have had to choose > > > > between > > > > retaining nosuid on a mount and allowing SELinux domain > > > > transitions on > > > > files within those mounts. This likewise leads to unfortunate > > > > tradeoffs > > > > in security. > > > > > > > > Decouple NNP/nosuid from SELinux transitions, so that we don't > > > > have to > > > > make a choice between them. Introduce a nnp_nosuid_transition > > > > policy > > > > capability that causes the ability to transition under NNP/nosuid > > > > to > > > > be based on a nnp_nosuid_transition permission between the old > > > > and new > > > > contexts rather than typebounds. Domain transitions can then be > > > > allowed > > > > in policy without requiring the parent to be a strict superset of > > > > all of > > > > its children. > > > > > > > > With this change, systemd unit files can be left unmodified from > > > > upstream. > > > > SELinux-disabled and SELinux-enabled users will benefit from > > > > retaining any > > > > of the systemd-provided protections. SELinux policy will only > > > > need to > > > > be adapted to enable the new policy capability and to allow the > > > > new permission between domain pairs as appropriate. > > > > > > A few things, the name is pretty awkward. my main issue with it is > > > what > > > if some other similar kind of thing is added in the future then > > > we'll > > > have nnp_nosuid_transition that should also cover it but the name > > > wont > > > cover it. > > > > Yes, I don't think anyone is in love with the name, but no one > > offered > > anything better; see the previous patch posting for some of that > > discussion. If you have a better suggestion I would love to hear it. > > Agreed, although I'm skeptical that there will be any "other similar > kind of thing" added in the future that we would want to cover under > the same permission. > > > > > > Why do we want to disallow type-bounds to work even with the > > > capability? > > > it seems sensible to me to allow typebounds to transition even in > > > the > > > future. If we do then we probably dont need the policycap which > > > seems > > > less complicated. > > > > The suggestion to continue to support bounded domain transitions > > seems > > reasonable to me, although we would need to worry about which check > > to > > do first (bounded transition or process:nnp_nosuid_transition), and > > how to limit the auditing/reporting so admins are confused by the > > first check failing, yet the transition still taking place. None of > > these are unsolvable problems, but it will likely need a bit more > > work. > > > > I'm sure Stephen has some thoughts on this as well. > > Others (e.g. Dominick) seemed to take the opposite view on the earlier > RFC discussion, i.e. that we should only check the new permission if > the capability is enabled. I specifically raised that as a question > there. > > I'm willing to change it to fallback to checking for a bounded type, > but that will mean two audit messages (I don't think we can just hide > one of them) when neither is allowed. That said, it is unlikely to > cause much confusion in practice because users typically only look for > and pay attention to AVC messages, and anyone using audit2allow will > just end up allowing the permission, not the bounds. > I am not opposed to that either. It might be useful. For example you might want to use type_bounds for containers and nnp_nosuid_transition for systemd services. This whole situation is already messy anyway with or without this. I just feel sorry for the support departments that need to support this. > > > > > also how are we thinking to do this in refpol? only add it > > > specifically > > > as needed? or would it be added to the execute_file_perms type > > > macros? > > > Although, grep typebounds is nowhere to be found currently in > > > either > > > refpol and gentoo's repo. > > > > I'm *really* hoping this new permission is only granted where > > absolutely needed, which I hope should be rather small (see the patch > > description and the discussion regarding systemd unit files). > > Actually, I'm not clear on that. If systemd continues to expand the > usage of these options in its unit files (which seems likely), then I > could see this ultimately affecting all service domains and all of > their descendants. If it was only going to be a handful of domains, > then the typebounds solution might be more tractable, albeit painful. >
On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> > > wrote: > > > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote: > > > > As systemd ramps up enabling NNP (NoNewPrivileges) for system > > > > services, > > > > it is increasingly breaking SELinux domain transitions for > > > > those > > > > services > > > > and their descendants. systemd enables NNP not only for > > > > services > > > > whose > > > > unit files explicitly specify NoNewPrivileges=yes but also for > > > > services > > > > whose unit files specify any of the following options in > > > > combination with > > > > running without CAP_SYS_ADMIN (e.g. specifying User= or a > > > > CapabilityBoundingSet= without CAP_SYS_ADMIN): > > > > SystemCallFilter=, > > > > SystemCallArchitectures=, RestrictAddressFamilies=, > > > > RestrictNamespaces=, > > > > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, > > > > MemoryDenyWriteExecute=, or RestrictRealtime= as per the > > > > systemd.exec(5) > > > > man page. > > > > > > > > The end result is bad for the security of both SELinux-disabled > > > > and > > > > SELinux-enabled systems. Packagers have to turn off these > > > > options in the unit files to preserve SELinux domain > > > > transitions. For > > > > users who choose to disable SELinux, this means that they miss > > > > out on > > > > at least having the systemd-supported protections. For users > > > > who > > > > keep > > > > SELinux enabled, they may still be missing out on some > > > > protections > > > > because it isn't necessarily guaranteed that the SELinux policy > > > > for > > > > that service provides the same protections in all cases. > > > > > > > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under > > > > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP > > > > in > > > > order to support limited usage for sandboxing > > > > programs. However, > > > > defining typebounds for all of the affected service domains > > > > is impractical to implement in policy, since typebounds > > > > requires > > > > us > > > > to ensure that each domain is allowed everything all of its > > > > descendant > > > > domains are allowed, and this has to be repeated for the entire > > > > chain > > > > of domain transitions. There is no way to clone all allow > > > > rules > > > > from > > > > descendants to their ancestors in policy currently, and doing > > > > so > > > > would > > > > be undesirable even if it were practical, as it requires > > > > leaking > > > > permissions to objects and operations into ancestor domains > > > > that > > > > could > > > > weaken their own security in order to allow them to the > > > > descendants > > > > (e.g. if a descendant requires execmem permission, then so do > > > > all > > > > of > > > > its ancestors; if a descendant requires execute permission to a > > > > file, > > > > then so do all of its ancestors; if a descendant requires read > > > > to > > > > a > > > > symbolic link or temporary file, then so do all of its > > > > ancestors...). > > > > SELinux domains are intentionally not hierarchical / bounded in > > > > this > > > > manner normally, and making them so would undermine their > > > > protections > > > > and least privilege. > > > > > > > > We have long had a similar tension with SELinux transitions and > > > > nosuid > > > > mounts, albeit not as severe. Users often have had to choose > > > > between > > > > retaining nosuid on a mount and allowing SELinux domain > > > > transitions on > > > > files within those mounts. This likewise leads to unfortunate > > > > tradeoffs > > > > in security. > > > > > > > > Decouple NNP/nosuid from SELinux transitions, so that we don't > > > > have to > > > > make a choice between them. Introduce a nnp_nosuid_transition > > > > policy > > > > capability that causes the ability to transition under > > > > NNP/nosuid > > > > to > > > > be based on a nnp_nosuid_transition permission between the old > > > > and new > > > > contexts rather than typebounds. Domain transitions can then > > > > be > > > > allowed > > > > in policy without requiring the parent to be a strict superset > > > > of > > > > all of > > > > its children. > > > > > > > > With this change, systemd unit files can be left unmodified > > > > from > > > > upstream. > > > > SELinux-disabled and SELinux-enabled users will benefit from > > > > retaining any > > > > of the systemd-provided protections. SELinux policy will only > > > > need to > > > > be adapted to enable the new policy capability and to allow the > > > > new permission between domain pairs as appropriate. > > > > > > A few things, the name is pretty awkward. my main issue with it > > > is > > > what > > > if some other similar kind of thing is added in the future then > > > we'll > > > have nnp_nosuid_transition that should also cover it but the name > > > wont > > > cover it. > > > > Yes, I don't think anyone is in love with the name, but no one > > offered > > anything better; see the previous patch posting for some of that > > discussion. If you have a better suggestion I would love to hear > > it. > > Agreed, although I'm skeptical that there will be any "other similar > kind of thing" added in the future that we would want to cover under > the same permission. > > > > > > Why do we want to disallow type-bounds to work even with the > > > capability? > > > it seems sensible to me to allow typebounds to transition even in > > > the > > > future. If we do then we probably dont need the policycap which > > > seems > > > less complicated. > > > > The suggestion to continue to support bounded domain transitions > > seems > > reasonable to me, although we would need to worry about which check > > to > > do first (bounded transition or process:nnp_nosuid_transition), and > > how to limit the auditing/reporting so admins are confused by the > > first check failing, yet the transition still taking place. None > > of > > these are unsolvable problems, but it will likely need a bit more > > work. > > > > I'm sure Stephen has some thoughts on this as well. > > Others (e.g. Dominick) seemed to take the opposite view on the > earlier > RFC discussion, i.e. that we should only check the new permission if > the capability is enabled. I specifically raised that as a question > there. > > I'm willing to change it to fallback to checking for a bounded type, > but that will mean two audit messages (I don't think we can just hide > one of them) when neither is allowed. That said, it is unlikely to > cause much confusion in practice because users typically only look > for > and pay attention to AVC messages, and anyone using audit2allow will > just end up allowing the permission, not the bounds. As Jason noted, if we fallback to checking for a bounded type, then we don't strictly need a policy capability for it. > > > > > > also how are we thinking to do this in refpol? only add it > > > specifically > > > as needed? or would it be added to the execute_file_perms type > > > macros? > > > Although, grep typebounds is nowhere to be found currently in > > > either > > > refpol and gentoo's repo. > > > > I'm *really* hoping this new permission is only granted where > > absolutely needed, which I hope should be rather small (see the > > patch > > description and the discussion regarding systemd unit files). > > Actually, I'm not clear on that. If systemd continues to expand the > usage of these options in its unit files (which seems likely), then I > could see this ultimately affecting all service domains and all of > their descendants. If it was only going to be a handful of domains, > then the typebounds solution might be more tractable, albeit painful.
On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> > > > > > > wrote: > > > > > > ... > > > > > > > > > > Why do we want to disallow type-bounds to work even with the > > > > > > > capability? > > > > > > > it seems sensible to me to allow typebounds to transition even in > > > > > > > the > > > > > > > future. If we do then we probably dont need the policycap which > > > > > > > seems > > > > > > > less complicated. > > > > > > > > > > > > The suggestion to continue to support bounded domain transitions > > > > > > seems > > > > > > reasonable to me, although we would need to worry about which check > > > > > > to > > > > > > do first (bounded transition or process:nnp_nosuid_transition), and > > > > > > how to limit the auditing/reporting so admins are confused by the > > > > > > first check failing, yet the transition still taking place. None > > > > > > of > > > > > > these are unsolvable problems, but it will likely need a bit more > > > > > > work. > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view on the > > > > > earlier > > > > > RFC discussion, i.e. that we should only check the new permission if > > > > > the capability is enabled. I specifically raised that as a question > > > > > there. > > > > > > > > > > I'm willing to change it to fallback to checking for a bounded type, > > > > > but that will mean two audit messages (I don't think we can just hide > > > > > one of them) when neither is allowed. That said, it is unlikely to > > > > > cause much confusion in practice because users typically only look > > > > > for > > > > > and pay attention to AVC messages, and anyone using audit2allow will > > > > > just end up allowing the permission, not the bounds. > > > > > > > > As Jason noted, if we fallback to checking for a bounded type, then we > > > > don't strictly need a policy capability for it. > > > > > > It seems as though Dominick is okay with the fallback, what do the > > > rest of the policy folks think about that approach? > > I am okay with the faillback > > > > > > > I'm of the opinion that changes which don't require a new policy > > > capability are slightly more favorable, but since one of the goals > > > with this change is to make policy development easier, I want to make > > > sure we are actually doing that. It would appear we are, but a few > > > explicit nods from the policy folks would be nice to see. > > > > With my coder hat on, I can see the value of having the existing behavior be > > available for anyone who currently uses it, so it makes sense. > > I agree, its only that I believe that no one is using it because it is impractical (except for mod_selinux users, and people that currently use type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. > The only scenario currently where, I believe, type_bounds might be prefered is containers since container process types do not change and the inheritance aspect is not much of a problem. > > > > > With my policy hat on, I don't have an opinion on a fallback. What I do > > know is I don't like typebounds, avoid it as much as possible, and strongly > > prefer it not be forced on me. There are no typebounds in refpolicy. > > > > In fact, I think NNP should not affecting SELinux at all as NNP is > > discretionary and SELinux is mandatory. NNP makes sense where you start out > > with lots of privileges and have to shed them, (i.e. the Linux > > DAC/capabilities perspective) whereas you have no privileges in SELinux > > except what is explicitly allowed. > > > > Once this permission is implemented I'll likely add the permission across > > most if not all transitions out of systemd. > > Yes but do not expect that to ,always, be enough due to the inheritance aspect. A process may have inherited the NNP flag, not because its started by systemd but because its started by a process that inherited the NNP flag because it was started by systemd. In dssp2 i have this concept called forked subject types, basically these are systemd daemons *and* any processes types transitioned to by systemd daemons. These are rules specific for systemd (system) forked subject types*: [root@julius ~]# sesearch -A -t systemd.system.forked_subj_type_attribute -dt allow systemd.system.subj systemd.system.forked_subj_type_attribute:process { getsched setrlimit setsched }; [root@julius ~]# sesearch -A -s systemd.system.forked_subj_type_attribute -ds allow systemd.system.forked_subj_type_attribute systemd.system.subj:fd use; allow systemd.system.forked_subj_type_attribute systemd.system.subj:unix_stream_socket { append bind connect getattr getopt ioctl read setattr setopt shutdown write }; Here are some types of process types that are (potentially) associated with children of systemd system daemons (but arent daemons themselves): [root@julius ~]# for i in `seinfo -xasystemd.system.forked_subj_type_attribute`; do [[ $(seinfo -xt $i | grep "systemd.system.daemon_subj_type_attribute") ]] || echo $i | grep ".subj$"; done apache.rotatelogs.subj bootloader.subj chage.subj dracut.subj fuse.fusermount.subj iputils.subj kernel_install.subj kexec_tools.mkdumprd.subj loadkeys.subj logger.subj mysql.daemon.utils.subj nm_openvpn.subj notify.subj nspawn.generic_container.subj resolve.subj semodule.subj seutils.load_policy.subj seutils.setfiles.subj sysadm_systemd.subj tunctl.subj udisks.lvm.subj user_systemd.subj usermanage.groupadd.subj usermanage.useradd.subj wheel_systemd.subj xserver.subj So if i were to use the nnp_nosuid_transition permission then i would probably associate it with systemd.system.forked_subj_type_attribute * output might not be accurate due to limitations CIL/setools > > > > > -- > > Chris PeBenito > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://secure-web.cisco.com/1p1yJD5SgewwVGBgT_zKJkJvFL8qog155yQggcavHJLjq48wjbhNA8aQVb-yKQytK0gkNSJhEmUqMNd7ObjKqKswecjvBELF3FoljHWmV5zG0pB2nieTMCq4GE3au_YNQm5K0alYZfpAYKBkjlB_W_Ggozlt-y4ubCZAZslUDrFPKKKD8bt3id7r7bbLHxRm9YHUfoGFUUIkGL_yDuJL3Sl1eg0m10DIZooifM6xADBJLIcRPkSRgIK2740270KkcloQimp3iGjxZS04dN6GpqA/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02 > Dominick Grift
On Tue, Jul 18, 2017 at 9:07 PM, Chris PeBenito <pebenito@ieee.org> wrote: > On 07/18/2017 05:26 PM, Paul Moore wrote: >> >> On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov> >> wrote: >>> >>> On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: >>>> >>>> On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: >>>>> >>>>> On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> >>>>> wrote: >> >> >> ... >> >>>>>> Why do we want to disallow type-bounds to work even with the >>>>>> capability? >>>>>> it seems sensible to me to allow typebounds to transition even in >>>>>> the >>>>>> future. If we do then we probably dont need the policycap which >>>>>> seems >>>>>> less complicated. >>>>> >>>>> >>>>> The suggestion to continue to support bounded domain transitions >>>>> seems >>>>> reasonable to me, although we would need to worry about which check >>>>> to >>>>> do first (bounded transition or process:nnp_nosuid_transition), and >>>>> how to limit the auditing/reporting so admins are confused by the >>>>> first check failing, yet the transition still taking place. None >>>>> of >>>>> these are unsolvable problems, but it will likely need a bit more >>>>> work. >>>>> >>>>> I'm sure Stephen has some thoughts on this as well. >>>> >>>> >>>> Others (e.g. Dominick) seemed to take the opposite view on the >>>> earlier >>>> RFC discussion, i.e. that we should only check the new permission if >>>> the capability is enabled. I specifically raised that as a question >>>> there. >>>> >>>> I'm willing to change it to fallback to checking for a bounded type, >>>> but that will mean two audit messages (I don't think we can just hide >>>> one of them) when neither is allowed. That said, it is unlikely to >>>> cause much confusion in practice because users typically only look >>>> for >>>> and pay attention to AVC messages, and anyone using audit2allow will >>>> just end up allowing the permission, not the bounds. >>> >>> >>> As Jason noted, if we fallback to checking for a bounded type, then we >>> don't strictly need a policy capability for it. >> >> >> It seems as though Dominick is okay with the fallback, what do the >> rest of the policy folks think about that approach? >> >> I'm of the opinion that changes which don't require a new policy >> capability are slightly more favorable, but since one of the goals >> with this change is to make policy development easier, I want to make >> sure we are actually doing that. It would appear we are, but a few >> explicit nods from the policy folks would be nice to see. > > With my coder hat on, I can see the value of having the existing behavior be > available for anyone who currently uses it, so it makes sense. > > With my policy hat on, I don't have an opinion on a fallback. What I do > know is I don't like typebounds, avoid it as much as possible, and strongly > prefer it not be forced on me. There are no typebounds in refpolicy. > > In fact, I think NNP should not affecting SELinux at all as NNP is > discretionary and SELinux is mandatory. NNP makes sense where you start out > with lots of privileges and have to shed them, (i.e. the Linux > DAC/capabilities perspective) whereas you have no privileges in SELinux > except what is explicitly allowed. > > Once this permission is implemented I'll likely add the permission across > most if not all transitions out of systemd. It seems that falling back to the bounded transition is the best way forward. Sorry to make you spin another version of the patch Stephen.
On Mon, Jul 17, 2017 at 4:06 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > At the risk of commenting on SELinux in general: > >> There is no way to clone all allow rules from >> descendants to their ancestors in policy currently, and doing so would >> be undesirable even if it were practical, as it requires leaking >> permissions to objects and operations into ancestor domains that could >> weaken their own security in order to allow them to the descendants >> (e.g. if a descendant requires execmem permission, then so do all of >> its ancestors ... > > In my mind, permissions like execmem aren't in the same category as > normal permissions. execmem is the right to do something that opens > the subject to compromise, not the right to do something to an object > that needs protection. Maybe execmem should be exempt from > typebounds. I just realized that this got lost in the rest of the discussion ... It's worth nothing that from a practical point of bounded type transitions aren't likely going to be the solution that will likely be used to solve this current systemd problem (see the rest of the thread). However, I understand you were speaking in general terms, and while there may be some merit to your suggestion, that would be quite a deviation from how things work at the moment and unless typebounds takes off (which I am beginning to doubt will happen outside a few special domains) I'm not sure it is worth the effort and headache.
On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> > > > > > > > wrote: > > > > > > > > ... > > > > > > > > > > > > Why do we want to disallow type-bounds to work even with the > > > > > > > > capability? > > > > > > > > it seems sensible to me to allow typebounds to transition even in > > > > > > > > the > > > > > > > > future. If we do then we probably dont need the policycap which > > > > > > > > seems > > > > > > > > less complicated. > > > > > > > > > > > > > > The suggestion to continue to support bounded domain transitions > > > > > > > seems > > > > > > > reasonable to me, although we would need to worry about which check > > > > > > > to > > > > > > > do first (bounded transition or process:nnp_nosuid_transition), and > > > > > > > how to limit the auditing/reporting so admins are confused by the > > > > > > > first check failing, yet the transition still taking place. None > > > > > > > of > > > > > > > these are unsolvable problems, but it will likely need a bit more > > > > > > > work. > > > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view on the > > > > > > earlier > > > > > > RFC discussion, i.e. that we should only check the new permission if > > > > > > the capability is enabled. I specifically raised that as a question > > > > > > there. > > > > > > > > > > > > I'm willing to change it to fallback to checking for a bounded type, > > > > > > but that will mean two audit messages (I don't think we can just hide > > > > > > one of them) when neither is allowed. That said, it is unlikely to > > > > > > cause much confusion in practice because users typically only look > > > > > > for > > > > > > and pay attention to AVC messages, and anyone using audit2allow will > > > > > > just end up allowing the permission, not the bounds. > > > > > > > > > > As Jason noted, if we fallback to checking for a bounded type, then we > > > > > don't strictly need a policy capability for it. > > > > > > > > It seems as though Dominick is okay with the fallback, what do the > > > > rest of the policy folks think about that approach? > > > > I am okay with the faillback > > > > > > > > > > I'm of the opinion that changes which don't require a new policy > > > > capability are slightly more favorable, but since one of the goals > > > > with this change is to make policy development easier, I want to make > > > > sure we are actually doing that. It would appear we are, but a few > > > > explicit nods from the policy folks would be nice to see. > > > > > > With my coder hat on, I can see the value of having the existing behavior be > > > available for anyone who currently uses it, so it makes sense. > > > > I agree, its only that I believe that no one is using it because it is impractical (except for mod_selinux users, and people that currently use type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. > > The only scenario currently where, I believe, type_bounds might be prefered is containers since container process types do not change and the inheritance aspect is not much of a problem. > > > > > > > > With my policy hat on, I don't have an opinion on a fallback. What I do > > > know is I don't like typebounds, avoid it as much as possible, and strongly > > > prefer it not be forced on me. There are no typebounds in refpolicy. > > > > > > In fact, I think NNP should not affecting SELinux at all as NNP is > > > discretionary and SELinux is mandatory. NNP makes sense where you start out > > > with lots of privileges and have to shed them, (i.e. the Linux > > > DAC/capabilities perspective) whereas you have no privileges in SELinux > > > except what is explicitly allowed. > > > > > > Once this permission is implemented I'll likely add the permission across > > > most if not all transitions out of systemd. > > > > Yes but do not expect that to ,always, be enough due to the inheritance aspect. A process may have inherited the NNP flag, not because its started by systemd but because its started by a process that inherited the NNP flag because it was started by systemd. > > In dssp2 i have this concept called forked subject types, basically these are systemd daemons *and* any processes types transitioned to by systemd daemons. > > These are rules specific for systemd (system) forked subject types*: > > [root@julius ~]# sesearch -A -t systemd.system.forked_subj_type_attribute -dt > allow systemd.system.subj systemd.system.forked_subj_type_attribute:process { getsched setrlimit setsched }; > > [root@julius ~]# sesearch -A -s systemd.system.forked_subj_type_attribute -ds > allow systemd.system.forked_subj_type_attribute systemd.system.subj:fd use; > allow systemd.system.forked_subj_type_attribute systemd.system.subj:unix_stream_socket { append bind connect getattr getopt ioctl read setattr setopt shutdown write }; > > Here are some types of process types that are (potentially) associated with children of systemd system daemons (but arent daemons themselves): > > [root@julius ~]# for i in `seinfo -xasystemd.system.forked_subj_type_attribute`; do [[ $(seinfo -xt $i | grep "systemd.system.daemon_subj_type_attribute") ]] || echo $i | grep ".subj$"; done > apache.rotatelogs.subj > bootloader.subj > chage.subj > dracut.subj > fuse.fusermount.subj > iputils.subj > kernel_install.subj > kexec_tools.mkdumprd.subj > loadkeys.subj > logger.subj > mysql.daemon.utils.subj > nm_openvpn.subj > notify.subj > nspawn.generic_container.subj > resolve.subj > semodule.subj > seutils.load_policy.subj > seutils.setfiles.subj > sysadm_systemd.subj > tunctl.subj > udisks.lvm.subj > user_systemd.subj > usermanage.groupadd.subj > usermanage.useradd.subj > wheel_systemd.subj > xserver.subj > > So if i were to use the nnp_nosuid_transition permission then i would probably associate it with systemd.system.forked_subj_type_attribute > > * output might not be accurate due to limitations CIL/setools By the way. If i am going to use nnp_nosuid_transition then am not going to "just" associate this permission. I am going to deal with this on a case by case basis. In the systemd world this concept is very common. Systemd "potentially" needs to be able to do a lot of things to assets owned by its children. If you generalize this then you might as well make systemd unconfined. Containing systemd is very expensive in terms of policy rules. I am starting to wonder whether it is even worth bothering. It is not just the state today. Things still escalate. It is getting worse by the day. > > > > > > > > > -- > > > Chris PeBenito > > > > -- > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://secure-web.cisco.com/1A_WrTj3kAjkwuBmWXg6PuoiAjXyH8UU-z-ApV2MDP3SSs0P2YkubSRbbCGiWxhWgNW5klo0gJ7QkLGwI7-11-jTt1HK7ypKpW7DtXtM4yOgy0_5N5yjCh3Ow77XpHYfc97klOQlmQONWNDBLC8rWkav3UqnwZHYhXbRyCqUA6iaRo6dq3FnPFa9IGl_iQuKdoTF1_-lhkKf-NPcuCWzcdMELJKhoFAQjnj3eu2j053TxFKhnVi_vCMqnqub0qfS7cGjZLJ7lPioFySKJn4J23g/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02 > > Dominick Grift > > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://secure-web.cisco.com/1A_WrTj3kAjkwuBmWXg6PuoiAjXyH8UU-z-ApV2MDP3SSs0P2YkubSRbbCGiWxhWgNW5klo0gJ7QkLGwI7-11-jTt1HK7ypKpW7DtXtM4yOgy0_5N5yjCh3Ow77XpHYfc97klOQlmQONWNDBLC8rWkav3UqnwZHYhXbRyCqUA6iaRo6dq3FnPFa9IGl_iQuKdoTF1_-lhkKf-NPcuCWzcdMELJKhoFAQjnj3eu2j053TxFKhnVi_vCMqnqub0qfS7cGjZLJ7lPioFySKJn4J23g/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02 > Dominick Grift
On 07/19/2017 05:31 PM, Dominick Grift wrote: > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: >> On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: >>> On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: >>>> On 07/18/2017 05:26 PM, Paul Moore wrote: >>>>> On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: >>>>>> On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: >>>>>>> On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: >>>>>>>> On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.com> >>>>>>>> wrote: >>>>> >>>>> ... >>>>> >>>>>>>>> Why do we want to disallow type-bounds to work even with the >>>>>>>>> capability? >>>>>>>>> it seems sensible to me to allow typebounds to transition even in >>>>>>>>> the >>>>>>>>> future. If we do then we probably dont need the policycap which >>>>>>>>> seems >>>>>>>>> less complicated. >>>>>>>> >>>>>>>> The suggestion to continue to support bounded domain transitions >>>>>>>> seems >>>>>>>> reasonable to me, although we would need to worry about which check >>>>>>>> to >>>>>>>> do first (bounded transition or process:nnp_nosuid_transition), and >>>>>>>> how to limit the auditing/reporting so admins are confused by the >>>>>>>> first check failing, yet the transition still taking place. None >>>>>>>> of >>>>>>>> these are unsolvable problems, but it will likely need a bit more >>>>>>>> work. >>>>>>>> >>>>>>>> I'm sure Stephen has some thoughts on this as well. >>>>>>> >>>>>>> Others (e.g. Dominick) seemed to take the opposite view on the >>>>>>> earlier >>>>>>> RFC discussion, i.e. that we should only check the new permission if >>>>>>> the capability is enabled. I specifically raised that as a question >>>>>>> there. >>>>>>> >>>>>>> I'm willing to change it to fallback to checking for a bounded type, >>>>>>> but that will mean two audit messages (I don't think we can just hide >>>>>>> one of them) when neither is allowed. That said, it is unlikely to >>>>>>> cause much confusion in practice because users typically only look >>>>>>> for >>>>>>> and pay attention to AVC messages, and anyone using audit2allow will >>>>>>> just end up allowing the permission, not the bounds. >>>>>> >>>>>> As Jason noted, if we fallback to checking for a bounded type, then we >>>>>> don't strictly need a policy capability for it. >>>>> >>>>> It seems as though Dominick is okay with the fallback, what do the >>>>> rest of the policy folks think about that approach? >>> >>> I am okay with the faillback >>> >>>>> >>>>> I'm of the opinion that changes which don't require a new policy >>>>> capability are slightly more favorable, but since one of the goals >>>>> with this change is to make policy development easier, I want to make >>>>> sure we are actually doing that. It would appear we are, but a few >>>>> explicit nods from the policy folks would be nice to see. >>>> >>>> With my coder hat on, I can see the value of having the existing behavior be >>>> available for anyone who currently uses it, so it makes sense. >>> >>> I agree, its only that I believe that no one is using it because it is impractical (except for mod_selinux users, and people that currently use type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. >>> The only scenario currently where, I believe, type_bounds might be prefered is containers since container process types do not change and the inheritance aspect is not much of a problem. >>> >>>> >>>> With my policy hat on, I don't have an opinion on a fallback. What I do >>>> know is I don't like typebounds, avoid it as much as possible, and strongly >>>> prefer it not be forced on me. There are no typebounds in refpolicy. >>>> >>>> In fact, I think NNP should not affecting SELinux at all as NNP is >>>> discretionary and SELinux is mandatory. NNP makes sense where you start out >>>> with lots of privileges and have to shed them, (i.e. the Linux >>>> DAC/capabilities perspective) whereas you have no privileges in SELinux >>>> except what is explicitly allowed. >>>> >>>> Once this permission is implemented I'll likely add the permission across >>>> most if not all transitions out of systemd. >>> >>> Yes but do not expect that to ,always, be enough due to the inheritance aspect. A process may have inherited the NNP flag, not because its started by systemd but because its started by a process that inherited the NNP flag because it was started by systemd. That just makes me want to apply the permission to all transitions for all domains. Not that I'm planning to do it in refpolicy. I'm definitely inclined to be very liberal in applying the permission in refpolicy. For my personal systems, I'd probably do an: allow domain domain:process nnp_nosuid_transition; so I don't ever have to think about it again.
On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: > On 07/19/2017 05:31 PM, Dominick Grift wrote: > > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > > > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > > > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > > > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho > > > > > > .nsa.gov> wrote: > > > > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@ > > > > > > > > > perfinion.com> > > > > > > > > > wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > Why do we want to disallow type-bounds to work even > > > > > > > > > > with the > > > > > > > > > > capability? > > > > > > > > > > it seems sensible to me to allow typebounds to > > > > > > > > > > transition even in > > > > > > > > > > the > > > > > > > > > > future. If we do then we probably dont need the > > > > > > > > > > policycap which > > > > > > > > > > seems > > > > > > > > > > less complicated. > > > > > > > > > > > > > > > > > > The suggestion to continue to support bounded domain > > > > > > > > > transitions > > > > > > > > > seems > > > > > > > > > reasonable to me, although we would need to worry > > > > > > > > > about which check > > > > > > > > > to > > > > > > > > > do first (bounded transition or > > > > > > > > > process:nnp_nosuid_transition), and > > > > > > > > > how to limit the auditing/reporting so admins are > > > > > > > > > confused by the > > > > > > > > > first check failing, yet the transition still taking > > > > > > > > > place. None > > > > > > > > > of > > > > > > > > > these are unsolvable problems, but it will likely > > > > > > > > > need a bit more > > > > > > > > > work. > > > > > > > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view > > > > > > > > on the > > > > > > > > earlier > > > > > > > > RFC discussion, i.e. that we should only check the new > > > > > > > > permission if > > > > > > > > the capability is enabled. I specifically raised that > > > > > > > > as a question > > > > > > > > there. > > > > > > > > > > > > > > > > I'm willing to change it to fallback to checking for a > > > > > > > > bounded type, > > > > > > > > but that will mean two audit messages (I don't think we > > > > > > > > can just hide > > > > > > > > one of them) when neither is allowed. That said, it is > > > > > > > > unlikely to > > > > > > > > cause much confusion in practice because users > > > > > > > > typically only look > > > > > > > > for > > > > > > > > and pay attention to AVC messages, and anyone using > > > > > > > > audit2allow will > > > > > > > > just end up allowing the permission, not the bounds. > > > > > > > > > > > > > > As Jason noted, if we fallback to checking for a bounded > > > > > > > type, then we > > > > > > > don't strictly need a policy capability for it. > > > > > > > > > > > > It seems as though Dominick is okay with the fallback, what > > > > > > do the > > > > > > rest of the policy folks think about that approach? > > > > > > > > I am okay with the faillback > > > > > > > > > > > > > > > > I'm of the opinion that changes which don't require a new > > > > > > policy > > > > > > capability are slightly more favorable, but since one of > > > > > > the goals > > > > > > with this change is to make policy development easier, I > > > > > > want to make > > > > > > sure we are actually doing that. It would appear we are, > > > > > > but a few > > > > > > explicit nods from the policy folks would be nice to see. > > > > > > > > > > With my coder hat on, I can see the value of having the > > > > > existing behavior be > > > > > available for anyone who currently uses it, so it makes > > > > > sense. > > > > > > > > I agree, its only that I believe that no one is using it > > > > because it is impractical (except for mod_selinux users, and > > > > people that currently use type_bounds to deal with nosuid),, > > > > mainly because the nnp flag is inherited. > > > > The only scenario currently where, I believe, type_bounds might > > > > be prefered is containers since container process types do not > > > > change and the inheritance aspect is not much of a problem. > > > > > > > > > > > > > > With my policy hat on, I don't have an opinion on a > > > > > fallback. What I do > > > > > know is I don't like typebounds, avoid it as much as > > > > > possible, and strongly > > > > > prefer it not be forced on me. There are no typebounds in > > > > > refpolicy. > > > > > > > > > > In fact, I think NNP should not affecting SELinux at all as > > > > > NNP is > > > > > discretionary and SELinux is mandatory. NNP makes sense > > > > > where you start out > > > > > with lots of privileges and have to shed them, (i.e. the > > > > > Linux > > > > > DAC/capabilities perspective) whereas you have no privileges > > > > > in SELinux > > > > > except what is explicitly allowed. > > > > > > > > > > Once this permission is implemented I'll likely add the > > > > > permission across > > > > > most if not all transitions out of systemd. > > > > > > > > Yes but do not expect that to ,always, be enough due to the > > > > inheritance aspect. A process may have inherited the NNP flag, > > > > not because its started by systemd but because its started by a > > > > process that inherited the NNP flag because it was started by > > > > systemd. > > That just makes me want to apply the permission to all transitions > for > all domains. Not that I'm planning to do it in refpolicy. I'm > definitely inclined to be very liberal in applying the permission in > refpolicy. For my personal systems, I'd probably do an: > > allow domain domain:process nnp_nosuid_transition; > > so I don't ever have to think about it again. Caveats: 1. It would mean that transitions on any removable media would be possible, even when marked nosuid. So, for example, if you were to mount (or have auto-mounted) removable media with nosuid but without noexec, and the removable media had been maliciously crafted with a file with an entrypoint type, then a user could use it to transition to a potentially more privileged SELinux domain, even though it could not gain capabilities or uid-0 that way (or, if the user can induce another process to execute from this filesystem, then this could produce a domain transition that would normally have been prevented). Ditto for network filesystems. This is perhaps an argument for introducing a separate check on nosuid; could be done via a file-based additional check (Can domain D nosuid_transition on file type T?) in addition to the nnp_nosuid_transition process-based permission check or by adding a process2 class and splitting nnp_nosuid_transition into nosuid_transition and nnp_transition process-based permissions. 2. It would mean that all domains could enable NNP, install seccomp filters (allowed for unprivileged processes if NNP is enabled), and execve a domain-changing program with those filters in effect, which could potentially lead to subverting the new domain. It is exactly for this reason that domain transitions under NNP were originally not allowed, and then only allowed for bounded transitions. Also note that NNP is intended to be used to open up other previously unsafe actions for unprivileged processes, so this could be extended to more than just seccomp in the future (examples given in the past have included chroot, certain unshare/clone flags, etc, although it seems like some of this has been obsoleted/replaced by user namespaces). So from a safety POV, you really only want to allow this when the calling domain is more trusted than the callee domain; think of it as being similar (but not equivalent) to noatsecure and/or dyntransition.
On Wed, 2017-07-19 at 17:08 -0400, Paul Moore wrote: > On Mon, Jul 17, 2017 at 4:06 PM, Andy Lutomirski <luto@kernel.org> > wrote: > > On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <sds@tycho.nsa.gov > > > wrote: > > > > At the risk of commenting on SELinux in general: > > > > > There is no way to clone all allow rules from > > > descendants to their ancestors in policy currently, and doing so > > > would > > > be undesirable even if it were practical, as it requires leaking > > > permissions to objects and operations into ancestor domains that > > > could > > > weaken their own security in order to allow them to the > > > descendants > > > (e.g. if a descendant requires execmem permission, then so do all > > > of > > > its ancestors ... > > > > In my mind, permissions like execmem aren't in the same category as > > normal permissions. execmem is the right to do something that > > opens > > the subject to compromise, not the right to do something to an > > object > > that needs protection. Maybe execmem should be exempt from > > typebounds. > > I just realized that this got lost in the rest of the discussion ... > > It's worth nothing that from a practical point of bounded type > transitions aren't likely going to be the solution that will likely > be > used to solve this current systemd problem (see the rest of the > thread). > > However, I understand you were speaking in general terms, and while > there may be some merit to your suggestion, that would be quite a > deviation from how things work at the moment and unless typebounds > takes off (which I am beginning to doubt will happen outside a few > special domains) I'm not sure it is worth the effort and headache. I also don't see how execmem is fundamentally different than the other examples I gave in the patch description; there would still be the problem of leaking execute access to files, read to symlinks, ...
On Thu, Jul 20, 2017 at 09:04:18AM -0400, Stephen Smalley wrote: > On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: > > On 07/19/2017 05:31 PM, Dominick Grift wrote: > > > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > > > > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > > > > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > > > > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > > > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho > > > > > > > .nsa.gov> wrote: > > > > > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@ > > > > > > > > > > perfinion.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Why do we want to disallow type-bounds to work even > > > > > > > > > > > with the > > > > > > > > > > > capability? > > > > > > > > > > > it seems sensible to me to allow typebounds to > > > > > > > > > > > transition even in > > > > > > > > > > > the > > > > > > > > > > > future. If we do then we probably dont need the > > > > > > > > > > > policycap which > > > > > > > > > > > seems > > > > > > > > > > > less complicated. > > > > > > > > > > > > > > > > > > > > The suggestion to continue to support bounded domain > > > > > > > > > > transitions > > > > > > > > > > seems > > > > > > > > > > reasonable to me, although we would need to worry > > > > > > > > > > about which check > > > > > > > > > > to > > > > > > > > > > do first (bounded transition or > > > > > > > > > > process:nnp_nosuid_transition), and > > > > > > > > > > how to limit the auditing/reporting so admins are > > > > > > > > > > confused by the > > > > > > > > > > first check failing, yet the transition still taking > > > > > > > > > > place. None > > > > > > > > > > of > > > > > > > > > > these are unsolvable problems, but it will likely > > > > > > > > > > need a bit more > > > > > > > > > > work. > > > > > > > > > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view > > > > > > > > > on the > > > > > > > > > earlier > > > > > > > > > RFC discussion, i.e. that we should only check the new > > > > > > > > > permission if > > > > > > > > > the capability is enabled. I specifically raised that > > > > > > > > > as a question > > > > > > > > > there. > > > > > > > > > > > > > > > > > > I'm willing to change it to fallback to checking for a > > > > > > > > > bounded type, > > > > > > > > > but that will mean two audit messages (I don't think we > > > > > > > > > can just hide > > > > > > > > > one of them) when neither is allowed. That said, it is > > > > > > > > > unlikely to > > > > > > > > > cause much confusion in practice because users > > > > > > > > > typically only look > > > > > > > > > for > > > > > > > > > and pay attention to AVC messages, and anyone using > > > > > > > > > audit2allow will > > > > > > > > > just end up allowing the permission, not the bounds. > > > > > > > > > > > > > > > > As Jason noted, if we fallback to checking for a bounded > > > > > > > > type, then we > > > > > > > > don't strictly need a policy capability for it. > > > > > > > > > > > > > > It seems as though Dominick is okay with the fallback, what > > > > > > > do the > > > > > > > rest of the policy folks think about that approach? > > > > > > > > > > I am okay with the faillback > > > > > > > > > > > > > > > > > > > I'm of the opinion that changes which don't require a new > > > > > > > policy > > > > > > > capability are slightly more favorable, but since one of > > > > > > > the goals > > > > > > > with this change is to make policy development easier, I > > > > > > > want to make > > > > > > > sure we are actually doing that. It would appear we are, > > > > > > > but a few > > > > > > > explicit nods from the policy folks would be nice to see. > > > > > > > > > > > > With my coder hat on, I can see the value of having the > > > > > > existing behavior be > > > > > > available for anyone who currently uses it, so it makes > > > > > > sense. > > > > > > > > > > I agree, its only that I believe that no one is using it > > > > > because it is impractical (except for mod_selinux users, and > > > > > people that currently use type_bounds to deal with nosuid),, > > > > > mainly because the nnp flag is inherited. > > > > > The only scenario currently where, I believe, type_bounds might > > > > > be prefered is containers since container process types do not > > > > > change and the inheritance aspect is not much of a problem. > > > > > > > > > > > > > > > > > With my policy hat on, I don't have an opinion on a > > > > > > fallback. What I do > > > > > > know is I don't like typebounds, avoid it as much as > > > > > > possible, and strongly > > > > > > prefer it not be forced on me. There are no typebounds in > > > > > > refpolicy. > > > > > > > > > > > > In fact, I think NNP should not affecting SELinux at all as > > > > > > NNP is > > > > > > discretionary and SELinux is mandatory. NNP makes sense > > > > > > where you start out > > > > > > with lots of privileges and have to shed them, (i.e. the > > > > > > Linux > > > > > > DAC/capabilities perspective) whereas you have no privileges > > > > > > in SELinux > > > > > > except what is explicitly allowed. > > > > > > > > > > > > Once this permission is implemented I'll likely add the > > > > > > permission across > > > > > > most if not all transitions out of systemd. > > > > > > > > > > Yes but do not expect that to ,always, be enough due to the > > > > > inheritance aspect. A process may have inherited the NNP flag, > > > > > not because its started by systemd but because its started by a > > > > > process that inherited the NNP flag because it was started by > > > > > systemd. > > > > That just makes me want to apply the permission to all transitions > > for > > all domains. Not that I'm planning to do it in refpolicy. I'm > > definitely inclined to be very liberal in applying the permission in > > refpolicy. For my personal systems, I'd probably do an: > > > > allow domain domain:process nnp_nosuid_transition; > > > > so I don't ever have to think about it again. > > Caveats: > > 1. It would mean that transitions on any removable media would be > possible, even when marked nosuid. So, for example, if you were to > mount (or have auto-mounted) removable media with nosuid but without > noexec, and the removable media had been maliciously crafted with a > file with an entrypoint type, then a user could use it to transition to > a potentially more privileged SELinux domain, even though it could not > gain capabilities or uid-0 that way (or, if the user can induce another > process to execute from this filesystem, then this could produce a > domain transition that would normally have been prevented). Ditto for > network filesystems. This is perhaps an argument for introducing a > separate check on nosuid; could be done via a file-based additional > check (Can domain D nosuid_transition on file type T?) in addition to > the nnp_nosuid_transition process-based permission check or by adding a > process2 class and splitting nnp_nosuid_transition into > nosuid_transition and nnp_transition process-based permissions. I like the idea of seperation. It addresses Jason's concerns about "if this functionality is extended then the identifier/permission name isnt accurate anymore", but it also makes things more clear and thereby easier to support. Plus it just provides more flexibility. It might be a little expensive, but i think we probably (or hopefully) end up associating these permissions with caution and not widely. > > 2. It would mean that all domains could enable NNP, install seccomp > filters (allowed for unprivileged processes if NNP is enabled), and > execve a domain-changing program with those filters in effect, which > could potentially lead to subverting the new domain. It is exactly for > this reason that domain transitions under NNP were originally not > allowed, and then only allowed for bounded transitions. Also note that > NNP is intended to be used to open up other previously unsafe actions > for unprivileged processes, so this could be extended to more than just > seccomp in the future (examples given in the past have included chroot, > certain unshare/clone flags, etc, although it seems like some of this > has been obsoleted/replaced by user namespaces). > > So from a safety POV, you really only want to allow this when the > calling domain is more trusted than the callee domain; think of it as > being similar (but not equivalent) to noatsecure and/or dyntransition. >
On 07/20/2017 09:04 AM, Stephen Smalley wrote: > On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: >> On 07/19/2017 05:31 PM, Dominick Grift wrote: >>> On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: >>>> On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: >>>>> On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: >>>>>> Once this permission is implemented I'll likely add the >>>>>> permission across >>>>>> most if not all transitions out of systemd. >>>>> >>>>> Yes but do not expect that to ,always, be enough due to the >>>>> inheritance aspect. A process may have inherited the NNP flag, >>>>> not because its started by systemd but because its started by a >>>>> process that inherited the NNP flag because it was started by >>>>> systemd. >> >> That just makes me want to apply the permission to all transitions >> for >> all domains. Not that I'm planning to do it in refpolicy. I'm >> definitely inclined to be very liberal in applying the permission in >> refpolicy. For my personal systems, I'd probably do an: >> >> allow domain domain:process nnp_nosuid_transition; >> >> so I don't ever have to think about it again. > > Caveats: > > 1. It would mean that transitions on any removable media would be > possible, even when marked nosuid. So, for example, if you were to > mount (or have auto-mounted) removable media with nosuid but without > noexec, and the removable media had been maliciously crafted with a > file with an entrypoint type, then a user could use it to transition to > a potentially more privileged SELinux domain, even though it could not > gain capabilities or uid-0 that way (or, if the user can induce another > process to execute from this filesystem, then this could produce a > domain transition that would normally have been prevented). Ditto for > network filesystems. This is perhaps an argument for introducing a > separate check on nosuid; could be done via a file-based additional > check (Can domain D nosuid_transition on file type T?) in addition to > the nnp_nosuid_transition process-based permission check or by adding a > process2 class and splitting nnp_nosuid_transition into > nosuid_transition and nnp_transition process-based permissions. This is a good point; however, if you're trusting removable media to do transitions on, you're already accepting a lot of risk of shooting yourself in the foot. While I understand the logic of the nosuid fs behavior, it's always bugged me because it's not obvious to most people. > 2. It would mean that all domains could enable NNP, install seccomp > filters (allowed for unprivileged processes if NNP is enabled), and > execve a domain-changing program with those filters in effect, which > could potentially lead to subverting the new domain. It is exactly for To make sure I understand, by subvert you mean the child domain would malfunction because of having less perms than required? > this reason that domain transitions under NNP were originally not > allowed, and then only allowed for bounded transitions. Also note that > NNP is intended to be used to open up other previously unsafe actions > for unprivileged processes, so this could be extended to more than just > seccomp in the future (examples given in the past have included chroot, > certain unshare/clone flags, etc, although it seems like some of this > has been obsoleted/replaced by user namespaces). > > So from a safety POV, you really only want to allow this when the > calling domain is more trusted than the callee domain; think of it as > being similar (but not equivalent) to noatsecure and/or dyntransition. Perhaps then the permission should be named something like nnp_nosuid_inh or inherit_nnp_nosuid or some variation thereof?
On Thu, 2017-07-20 at 17:08 -0400, Chris PeBenito wrote: > On 07/20/2017 09:04 AM, Stephen Smalley wrote: > > On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: > > > On 07/19/2017 05:31 PM, Dominick Grift wrote: > > > > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > > > > > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift > > > > > wrote: > > > > > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito > > > > > > wrote: > > > > > > > Once this permission is implemented I'll likely add the > > > > > > > permission across > > > > > > > most if not all transitions out of systemd. > > > > > > > > > > > > Yes but do not expect that to ,always, be enough due to the > > > > > > inheritance aspect. A process may have inherited the NNP > > > > > > flag, > > > > > > not because its started by systemd but because its started > > > > > > by a > > > > > > process that inherited the NNP flag because it was started > > > > > > by > > > > > > systemd. > > > > > > That just makes me want to apply the permission to all > > > transitions > > > for > > > all domains. Not that I'm planning to do it in refpolicy. I'm > > > definitely inclined to be very liberal in applying the permission > > > in > > > refpolicy. For my personal systems, I'd probably do an: > > > > > > allow domain domain:process nnp_nosuid_transition; > > > > > > so I don't ever have to think about it again. > > > > Caveats: > > > > 1. It would mean that transitions on any removable media would be > > possible, even when marked nosuid. So, for example, if you were to > > mount (or have auto-mounted) removable media with nosuid but > > without > > noexec, and the removable media had been maliciously crafted with a > > file with an entrypoint type, then a user could use it to > > transition to > > a potentially more privileged SELinux domain, even though it could > > not > > gain capabilities or uid-0 that way (or, if the user can induce > > another > > process to execute from this filesystem, then this could produce a > > domain transition that would normally have been prevented). Ditto > > for > > network filesystems. This is perhaps an argument for introducing a > > separate check on nosuid; could be done via a file-based additional > > check (Can domain D nosuid_transition on file type T?) in addition > > to > > the nnp_nosuid_transition process-based permission check or by > > adding a > > process2 class and splitting nnp_nosuid_transition into > > nosuid_transition and nnp_transition process-based permissions. > > This is a good point; however, if you're trusting removable media to > do > transitions on, you're already accepting a lot of risk of shooting > yourself in the foot. Exactly, which is why allowing transitions under nosuid could be dangerous, since nosuid is the traditional way of indicating that you don't trust the filesystem. > While I understand the logic of the nosuid fs > behavior, it's always bugged me because it's not obvious to most > people. On second thought, a file-based check doesn't really help here, since the file label is untrusted in this scenario. So it only really makes sense to introduce another process permission if we want to distinguish transitions on nosuid from transitions under nnp, but that requires adding a process2 class. > > 2. It would mean that all domains could enable NNP, install seccomp > > filters (allowed for unprivileged processes if NNP is enabled), and > > execve a domain-changing program with those filters in effect, > > which > > could potentially lead to subverting the new domain. It is exactly > > for > > To make sure I understand, by subvert you mean the child domain > would > malfunction because of having less perms than required? > Not less perms, but changed behavior when it invokes system calls (based on the seccomp bpf filters). The callee could set up seccomp filters that will cause the newly executed program to be killed at arbitrary points, to invoke system calls with altered arguments, or to return from certain system calls without actually executing them. Seccomp filters are inherited across execve; safety is provided by requiring that the task that installs the filter either have NNP enabled or have CAP_SYS_ADMIN in its user namespace. > > this reason that domain transitions under NNP were originally not > > allowed, and then only allowed for bounded transitions. Also note > > that > > NNP is intended to be used to open up other previously unsafe > > actions > > for unprivileged processes, so this could be extended to more than > > just > > seccomp in the future (examples given in the past have included > > chroot, > > certain unshare/clone flags, etc, although it seems like some of > > this > > has been obsoleted/replaced by user namespaces). > > > > So from a safety POV, you really only want to allow this when the > > calling domain is more trusted than the callee domain; think of it > > as > > being similar (but not equivalent) to noatsecure and/or > > dyntransition. > > Perhaps then the permission should be named something like > nnp_nosuid_inh or inherit_nnp_nosuid or some variation thereof? It might make sense to separately introduce a seccompinh permission or similar to control whether seccomp filters can be inherited across a domain transition. That's independent of whether we allow transitions under NNP and/or nosuid. I'm starting to think it is a mistake to treat NNP and nosuid transitions the same way, given the differences above. And I think the only way I can support that sanely is by adding a process2 class. So maybe we just need to do that.
On Tue, 2017-07-18 at 15:20 -0400, Stephen Smalley wrote: > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@perfinion.co > > > m> > > > wrote: > > > > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley > > > > wrote: > > > > > As systemd ramps up enabling NNP (NoNewPrivileges) for system > > > > > services, > > > > > it is increasingly breaking SELinux domain transitions for > > > > > those > > > > > services > > > > > and their descendants. systemd enables NNP not only for > > > > > services > > > > > whose > > > > > unit files explicitly specify NoNewPrivileges=yes but also > > > > > for > > > > > services > > > > > whose unit files specify any of the following options in > > > > > combination with > > > > > running without CAP_SYS_ADMIN (e.g. specifying User= or a > > > > > CapabilityBoundingSet= without CAP_SYS_ADMIN): > > > > > SystemCallFilter=, > > > > > SystemCallArchitectures=, RestrictAddressFamilies=, > > > > > RestrictNamespaces=, > > > > > PrivateDevices=, ProtectKernelTunables=, > > > > > ProtectKernelModules=, > > > > > MemoryDenyWriteExecute=, or RestrictRealtime= as per the > > > > > systemd.exec(5) > > > > > man page. > > > > > > > > > > The end result is bad for the security of both SELinux- > > > > > disabled > > > > > and > > > > > SELinux-enabled systems. Packagers have to turn off these > > > > > options in the unit files to preserve SELinux domain > > > > > transitions. For > > > > > users who choose to disable SELinux, this means that they > > > > > miss > > > > > out on > > > > > at least having the systemd-supported protections. For users > > > > > who > > > > > keep > > > > > SELinux enabled, they may still be missing out on some > > > > > protections > > > > > because it isn't necessarily guaranteed that the SELinux > > > > > policy > > > > > for > > > > > that service provides the same protections in all cases. > > > > > > > > > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions > > > > > under > > > > > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under > > > > > NNP > > > > > in > > > > > order to support limited usage for sandboxing > > > > > programs. However, > > > > > defining typebounds for all of the affected service domains > > > > > is impractical to implement in policy, since typebounds > > > > > requires > > > > > us > > > > > to ensure that each domain is allowed everything all of its > > > > > descendant > > > > > domains are allowed, and this has to be repeated for the > > > > > entire > > > > > chain > > > > > of domain transitions. There is no way to clone all allow > > > > > rules > > > > > from > > > > > descendants to their ancestors in policy currently, and doing > > > > > so > > > > > would > > > > > be undesirable even if it were practical, as it requires > > > > > leaking > > > > > permissions to objects and operations into ancestor domains > > > > > that > > > > > could > > > > > weaken their own security in order to allow them to the > > > > > descendants > > > > > (e.g. if a descendant requires execmem permission, then so do > > > > > all > > > > > of > > > > > its ancestors; if a descendant requires execute permission to > > > > > a > > > > > file, > > > > > then so do all of its ancestors; if a descendant requires > > > > > read > > > > > to > > > > > a > > > > > symbolic link or temporary file, then so do all of its > > > > > ancestors...). > > > > > SELinux domains are intentionally not hierarchical / bounded > > > > > in > > > > > this > > > > > manner normally, and making them so would undermine their > > > > > protections > > > > > and least privilege. > > > > > > > > > > We have long had a similar tension with SELinux transitions > > > > > and > > > > > nosuid > > > > > mounts, albeit not as severe. Users often have had to choose > > > > > between > > > > > retaining nosuid on a mount and allowing SELinux domain > > > > > transitions on > > > > > files within those mounts. This likewise leads to > > > > > unfortunate > > > > > tradeoffs > > > > > in security. > > > > > > > > > > Decouple NNP/nosuid from SELinux transitions, so that we > > > > > don't > > > > > have to > > > > > make a choice between them. Introduce a nnp_nosuid_transition > > > > > policy > > > > > capability that causes the ability to transition under > > > > > NNP/nosuid > > > > > to > > > > > be based on a nnp_nosuid_transition permission between the > > > > > old > > > > > and new > > > > > contexts rather than typebounds. Domain transitions can then > > > > > be > > > > > allowed > > > > > in policy without requiring the parent to be a strict > > > > > superset > > > > > of > > > > > all of > > > > > its children. > > > > > > > > > > With this change, systemd unit files can be left unmodified > > > > > from > > > > > upstream. > > > > > SELinux-disabled and SELinux-enabled users will benefit from > > > > > retaining any > > > > > of the systemd-provided protections. SELinux policy will > > > > > only > > > > > need to > > > > > be adapted to enable the new policy capability and to allow > > > > > the > > > > > new permission between domain pairs as appropriate. > > > > > > > > A few things, the name is pretty awkward. my main issue with it > > > > is > > > > what > > > > if some other similar kind of thing is added in the future then > > > > we'll > > > > have nnp_nosuid_transition that should also cover it but the > > > > name > > > > wont > > > > cover it. > > > > > > Yes, I don't think anyone is in love with the name, but no one > > > offered > > > anything better; see the previous patch posting for some of that > > > discussion. If you have a better suggestion I would love to hear > > > it. > > > > Agreed, although I'm skeptical that there will be any "other > > similar > > kind of thing" added in the future that we would want to cover > > under > > the same permission. > > > > > > > > > Why do we want to disallow type-bounds to work even with the > > > > capability? > > > > it seems sensible to me to allow typebounds to transition even > > > > in > > > > the > > > > future. If we do then we probably dont need the policycap which > > > > seems > > > > less complicated. > > > > > > The suggestion to continue to support bounded domain transitions > > > seems > > > reasonable to me, although we would need to worry about which > > > check > > > to > > > do first (bounded transition or process:nnp_nosuid_transition), > > > and > > > how to limit the auditing/reporting so admins are confused by the > > > first check failing, yet the transition still taking place. None > > > of > > > these are unsolvable problems, but it will likely need a bit more > > > work. > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > Others (e.g. Dominick) seemed to take the opposite view on the > > earlier > > RFC discussion, i.e. that we should only check the new permission > > if > > the capability is enabled. I specifically raised that as a > > question > > there. > > > > I'm willing to change it to fallback to checking for a bounded > > type, > > but that will mean two audit messages (I don't think we can just > > hide > > one of them) when neither is allowed. That said, it is unlikely to > > cause much confusion in practice because users typically only look > > for > > and pay attention to AVC messages, and anyone using audit2allow > > will > > just end up allowing the permission, not the bounds. > > As Jason noted, if we fallback to checking for a bounded type, then > we > don't strictly need a policy capability for it. Sorry, the above isn't correct. If we don't make the new check conditional on a policy capability, then the new permission will always be allowed under existing policies that have handle_unknown=allow (e.g. Fedora) and therefore new kernels would suddenly allow all transitions under NNP with old/existing policies. So I think we still need a policy capability for this change. > > > > > > > > > > also how are we thinking to do this in refpol? only add it > > > > specifically > > > > as needed? or would it be added to the execute_file_perms type > > > > macros? > > > > Although, grep typebounds is nowhere to be found currently in > > > > either > > > > refpol and gentoo's repo. > > > > > > I'm *really* hoping this new permission is only granted where > > > absolutely needed, which I hope should be rather small (see the > > > patch > > > description and the discussion regarding systemd unit files). > > > > Actually, I'm not clear on that. If systemd continues to expand > > the > > usage of these options in its unit files (which seems likely), then > > I > > could see this ultimately affecting all service domains and all of > > their descendants. If it was only going to be a handful of > > domains, > > then the typebounds solution might be more tractable, albeit > > painful.
On Thu, Jul 20, 2017 at 6:13 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Wed, 2017-07-19 at 17:08 -0400, Paul Moore wrote: >> On Mon, Jul 17, 2017 at 4:06 PM, Andy Lutomirski <luto@kernel.org> >> wrote: >> > On Fri, Jul 14, 2017 at 9:46 AM, Stephen Smalley <sds@tycho.nsa.gov >> > > wrote: >> > >> > At the risk of commenting on SELinux in general: >> > >> > > There is no way to clone all allow rules from >> > > descendants to their ancestors in policy currently, and doing so >> > > would >> > > be undesirable even if it were practical, as it requires leaking >> > > permissions to objects and operations into ancestor domains that >> > > could >> > > weaken their own security in order to allow them to the >> > > descendants >> > > (e.g. if a descendant requires execmem permission, then so do all >> > > of >> > > its ancestors ... >> > >> > In my mind, permissions like execmem aren't in the same category as >> > normal permissions. execmem is the right to do something that >> > opens >> > the subject to compromise, not the right to do something to an >> > object >> > that needs protection. Maybe execmem should be exempt from >> > typebounds. >> >> I just realized that this got lost in the rest of the discussion ... >> >> It's worth nothing that from a practical point of bounded type >> transitions aren't likely going to be the solution that will likely >> be >> used to solve this current systemd problem (see the rest of the >> thread). >> >> However, I understand you were speaking in general terms, and while >> there may be some merit to your suggestion, that would be quite a >> deviation from how things work at the moment and unless typebounds >> takes off (which I am beginning to doubt will happen outside a few >> special domains) I'm not sure it is worth the effort and headache. > > I also don't see how execmem is fundamentally different than the other > examples I gave in the patch description; there would still be the > problem of leaking execute access to files, read to symlinks, ... > It depends on exactly what the goal is. For conventional security, if you can play evil games and get a privilege to, say, write a file, then SELinux or its policy has failed. If you can play evil games and get execmem, it's not really a big deal. If you're running an app store and trying to completely prevent the execution of unsigned binary code, that's a different story, but it doesn't seem like the existing SELinux policy language is really geared toward this use case.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 3a06afb..932b72d 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm, return 0; /* No change in credentials */ /* - * The only transitions we permit under NNP or nosuid - * are transitions to bounded SIDs, i.e. SIDs that are - * guaranteed to only be allowed a subset of the permissions - * of the current SID. + * If the policy enables the nnp_nosuid_transition policy capability, + * then we permit transitions under NNP or nosuid if the + * policy explicitly allows nnp_nosuid_transition permission between + * the old and new contexts. */ - rc = security_bounded_transition(old_tsec->sid, new_tsec->sid); - if (rc) { + if (selinux_policycap_nnp_nosuid_transition) { + rc = avc_has_perm(old_tsec->sid, new_tsec->sid, + SECCLASS_PROCESS, + PROCESS__NNP_NOSUID_TRANSITION, NULL); + if (!rc) + return 0; + } else { /* - * On failure, preserve the errno values for NNP vs nosuid. - * NNP: Operation not permitted for caller. - * nosuid: Permission denied to file. + * Otherwise, the only transitions we permit under NNP or nosuid + * are transitions to bounded SIDs, i.e. SIDs that are + * guaranteed to only be allowed a subset of the permissions + * of the current SID. */ - if (nnp) - return -EPERM; - else - return -EACCES; + rc = security_bounded_transition(old_tsec->sid, new_tsec->sid); + if (!rc) + return 0; } - return 0; + + /* + * On failure, preserve the errno values for NNP vs nosuid. + * NNP: Operation not permitted for caller. + * nosuid: Permission denied to file. + */ + if (nnp) + return -EPERM; + return -EACCES; } static int selinux_bprm_set_creds(struct linux_binprm *bprm) diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h index b9fe343..dff81b8 100644 --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = { "getattr", "setexec", "setfscreate", "noatsecure", "siginh", "setrlimit", "rlimitinh", "dyntransition", "setcurrent", "execmem", "execstack", "execheap", "setkeycreate", - "setsockcreate", "getrlimit", NULL } }, + "setsockcreate", "getrlimit", "nnp_nosuid_transition", NULL } }, { "system", { "ipc_info", "syslog_read", "syslog_mod", "syslog_console", "module_request", "module_load", NULL } }, diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h index e91f08c..3e32317 100644 --- a/security/selinux/include/security.h +++ b/security/selinux/include/security.h @@ -73,6 +73,7 @@ enum { POLICYDB_CAPABILITY_EXTSOCKCLASS, POLICYDB_CAPABILITY_ALWAYSNETWORK, POLICYDB_CAPABILITY_CGROUPSECLABEL, + POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION, __POLICYDB_CAPABILITY_MAX }; #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1) @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm; extern int selinux_policycap_extsockclass; extern int selinux_policycap_alwaysnetwork; extern int selinux_policycap_cgroupseclabel; +extern int selinux_policycap_nnp_nosuid_transition; /* * type_datum properties diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index 2f02fa6..16c55de 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -76,7 +76,8 @@ char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = { "open_perms", "extended_socket_class", "always_check_network", - "cgroup_seclabel" + "cgroup_seclabel", + "nnp_nosuid_transition" }; int selinux_policycap_netpeer; @@ -84,6 +85,7 @@ int selinux_policycap_openperm; int selinux_policycap_extsockclass; int selinux_policycap_alwaysnetwork; int selinux_policycap_cgroupseclabel; +int selinux_policycap_nnp_nosuid_transition; static DEFINE_RWLOCK(policy_rwlock); @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void) selinux_policycap_cgroupseclabel = ebitmap_get_bit(&policydb.policycaps, POLICYDB_CAPABILITY_CGROUPSECLABEL); + selinux_policycap_nnp_nosuid_transition = + ebitmap_get_bit(&policydb.policycaps, + POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION); for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++) pr_info("SELinux: policy capability %s=%d\n",
As systemd ramps up enabling NNP (NoNewPrivileges) for system services, it is increasingly breaking SELinux domain transitions for those services and their descendants. systemd enables NNP not only for services whose unit files explicitly specify NoNewPrivileges=yes but also for services whose unit files specify any of the following options in combination with running without CAP_SYS_ADMIN (e.g. specifying User= or a CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5) man page. The end result is bad for the security of both SELinux-disabled and SELinux-enabled systems. Packagers have to turn off these options in the unit files to preserve SELinux domain transitions. For users who choose to disable SELinux, this means that they miss out on at least having the systemd-supported protections. For users who keep SELinux enabled, they may still be missing out on some protections because it isn't necessarily guaranteed that the SELinux policy for that service provides the same protections in all cases. commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in order to support limited usage for sandboxing programs. However, defining typebounds for all of the affected service domains is impractical to implement in policy, since typebounds requires us to ensure that each domain is allowed everything all of its descendant domains are allowed, and this has to be repeated for the entire chain of domain transitions. There is no way to clone all allow rules from descendants to their ancestors in policy currently, and doing so would be undesirable even if it were practical, as it requires leaking permissions to objects and operations into ancestor domains that could weaken their own security in order to allow them to the descendants (e.g. if a descendant requires execmem permission, then so do all of its ancestors; if a descendant requires execute permission to a file, then so do all of its ancestors; if a descendant requires read to a symbolic link or temporary file, then so do all of its ancestors...). SELinux domains are intentionally not hierarchical / bounded in this manner normally, and making them so would undermine their protections and least privilege. We have long had a similar tension with SELinux transitions and nosuid mounts, albeit not as severe. Users often have had to choose between retaining nosuid on a mount and allowing SELinux domain transitions on files within those mounts. This likewise leads to unfortunate tradeoffs in security. Decouple NNP/nosuid from SELinux transitions, so that we don't have to make a choice between them. Introduce a nnp_nosuid_transition policy capability that causes the ability to transition under NNP/nosuid to be based on a nnp_nosuid_transition permission between the old and new contexts rather than typebounds. Domain transitions can then be allowed in policy without requiring the parent to be a strict superset of all of its children. With this change, systemd unit files can be left unmodified from upstream. SELinux-disabled and SELinux-enabled users will benefit from retaining any of the systemd-provided protections. SELinux policy will only need to be adapted to enable the new policy capability and to allow the new permission between domain pairs as appropriate. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> --- security/selinux/hooks.c | 41 ++++++++++++++++++++++++------------- security/selinux/include/classmap.h | 2 +- security/selinux/include/security.h | 2 ++ security/selinux/ss/services.c | 7 ++++++- 4 files changed, 36 insertions(+), 16 deletions(-)