Re: [PATCH v2 2/8] exec: Move security_bprm_secureexec() earlier
On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman wrote: > Kees Cook writes: > >> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman >> wrote: >>> Kees Cook writes: >>> There are several places where exec needs to know if a privilege-gain has happened. These should be using the results of security_bprm_secureexec() but it is getting (needlessly) called very late. >>> >>> It is hard to tell at a glance but I believe this introduces a >>> regression. >>> >>> cap_bprm_set_creds is currently called before cap_bprm_secureexec and >>> it has a number of cases such as no_new_privs and ptrace that can result >>> in some of the precomputed credential changes not happening. >>> >>> Without accounting for that I believe your cap_bprm_securexec now >>> returns a postive value too early. >> >> It's still before cap_bprm_secureexec. cap_brpm_set_creds() is in >> prepare_binprm(), which is well before exec_binprm() and it's eventual >> call to setup_new_exec(). > > Good point. I didn't double check and the set in the name had me > thinking it was setting the creds on current. > > Is there any reason we need a second security hook? It feels like we > should be able to just fold the secureexec hook into the set_creds hook. > > The two are so interrelated I fear that having them separate only > encourages them to diverge in trivial ways as it is easy to forget about > some detail or other. > > Certainly having them called from different functions seems wrong. If > we know enough in prepare_binprm we know enough. Hmmm, yes. That would let us have the secureexec-ness knowledge before copy_strings(), in case we ever need to make that logic secureexec-aware. I'll dig through the LSMs to examine the set_creds hooks to see if this could be possible. -Kees -- Kees Cook Pixel Security
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> As systemd ramps up enabling NoNewPrivileges (either explicitly in
> service unit files or as a side effect of other security-related
> settings in service unit files), we're increasingly running afoul of
> its interactions with SELinux.
>
> 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.
>
> Our options seem to be:
>
> 1) Just keep on the way we are now, i.e. packagers have to remove
> default protection settings from upstream package unit files in order
> to have them work with SELinux (and not just NoNewPrivileges=
> itself; increasingly systemd is enabling NNP as a side effect of
> other
> unit file options, even seemingly unrelated ones like
> PrivateDevices).
> SELinux-disabled users lose entirely, SELinux-enabled users may lose
> (depending on whether SELinux policy provides equivalent or
> better guarantees).
>
> 2) Change systemd to automatically disable NNP on SELinux-enabled
> systems. Unit files can be left unmodified from upstream. SELinux-
> disabled users win. SELinux-enabled users may lose.
>
> 3) Try to use typebounds, since we allow bounded transitions under
> NNP.
> Unit files can be left unmodified from upstream. SELinux-disabled
> users
> win. SELinux-enabled users get to benefit from systemd-provided
> protections. However, this option is impractical to implement in
> policy
> currently, 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 children to the parent in policy
> currently, and it is doubtful that doing so would be desirable even
> if
> it were practical, as it requires leaking permissions to objects and
> operations into parent domains that could weaken their own security
> in
> order to allow them to the children (e.g. if a child requires execmem
> permission, then so does the parent; if a child requires read to a
> symbolic
> link or temporary file that it can write, then so does the parent,
> ...).
>
> 4) Decouple NNP from SELinux transitions, so that we don't have to
> make a choice between them. Introduce a new policy capability that
> causes the ability to transition under NNP to be based on a new
> permission
> check 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. The rationale for
> this
> divergence from NNP behavior for capabilities is that SELinux
> permissions
> are substantially broader than just capabilities (they express a full
> access matrix, not just privileges) and can only be used to further
> restrict capabilities, not grant them beyond what is already
> permitted.
> Unit files can be left unmodified from upstream. SELinux-disabled
> users
> win. SELinux-enabled users can benefit from systemd-provided
> protections
> and policy won't need to radically change.
>
> This change takes the last approach above, as it seems to be the
> best option.
>
> Signed-off-by: Stephen Smalley
> ---
> 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..f0c11c2 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_transition policy
> capability,
> + * then we permit transitions under NNP or nosuid if the
> + * policy explicitly allows nnp_transition permission
> between
> + * the old and new contexts.
> */
> - rc = security_bounded_transition(old_tsec->sid, new_tsec-
> >sid);
> - if (rc) {
> + if (selinux_policycap_nnptransition) {
> + rc = avc_has_perm(old_tsec->sid, new_tse
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > As systemd ramps up enabling NoNewPrivileges (either explicitly in > > service unit files or as a side effect of other security-related > > settings in service unit files), we're increasingly running afoul of > > its interactions with SELinux. > > > > 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. > > > > Our options seem to be: > > > > 1) Just keep on the way we are now, i.e. packagers have to remove > > default protection settings from upstream package unit files in order > > to have them work with SELinux (and not just NoNewPrivileges= > > itself; increasingly systemd is enabling NNP as a side effect of > > other > > unit file options, even seemingly unrelated ones like > > PrivateDevices). > > SELinux-disabled users lose entirely, SELinux-enabled users may lose > > (depending on whether SELinux policy provides equivalent or > > better guarantees). > > > > 2) Change systemd to automatically disable NNP on SELinux-enabled > > systems. Unit files can be left unmodified from upstream. SELinux- > > disabled users win. SELinux-enabled users may lose. > > > > 3) Try to use typebounds, since we allow bounded transitions under > > NNP. > > Unit files can be left unmodified from upstream. SELinux-disabled > > users > > win. SELinux-enabled users get to benefit from systemd-provided > > protections. However, this option is impractical to implement in > > policy > > currently, 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 children to the parent in policy > > currently, and it is doubtful that doing so would be desirable even > > if > > it were practical, as it requires leaking permissions to objects and > > operations into parent domains that could weaken their own security > > in > > order to allow them to the children (e.g. if a child requires execmem > > permission, then so does the parent; if a child requires read to a > > symbolic > > link or temporary file that it can write, then so does the parent, > > ...). > > > > 4) Decouple NNP from SELinux transitions, so that we don't have to > > make a choice between them. Introduce a new policy capability that > > causes the ability to transition under NNP to be based on a new > > permission > > check 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. The rationale for > > this > > divergence from NNP behavior for capabilities is that SELinux > > permissions > > are substantially broader than just capabilities (they express a full > > access matrix, not just privileges) and can only be used to further > > restrict capabilities, not grant them beyond what is already > > permitted. > > Unit files can be left unmodified from upstream. SELinux-disabled > > users > > win. SELinux-enabled users can benefit from systemd-provided > > protections > > and policy won't need to radically change. > > > > This change takes the last approach above, as it seems to be the > > best option. > > > > Signed-off-by: Stephen Smalley > > --- > > 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..f0c11c2 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_transition policy > > capability, > > + * then we permit transitions under NNP or nosuid if the > > + * policy explicitly allows nnp_transition p
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > As systemd ramps up enabling NoNewPrivileges (either explicitly in > > > service unit files or as a side effect of other security-related > > > settings in service unit files), we're increasingly running afoul of > > > its interactions with SELinux. > > > > > > 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. > > > > > > Our options seem to be: > > > > > > 1) Just keep on the way we are now, i.e. packagers have to remove > > > default protection settings from upstream package unit files in order > > > to have them work with SELinux (and not just NoNewPrivileges= > > > itself; increasingly systemd is enabling NNP as a side effect of > > > other > > > unit file options, even seemingly unrelated ones like > > > PrivateDevices). > > > SELinux-disabled users lose entirely, SELinux-enabled users may lose > > > (depending on whether SELinux policy provides equivalent or > > > better guarantees). > > > > > > 2) Change systemd to automatically disable NNP on SELinux-enabled > > > systems. Unit files can be left unmodified from upstream. SELinux- > > > disabled users win. SELinux-enabled users may lose. > > > > > > 3) Try to use typebounds, since we allow bounded transitions under > > > NNP. > > > Unit files can be left unmodified from upstream. SELinux-disabled > > > users > > > win. SELinux-enabled users get to benefit from systemd-provided > > > protections. However, this option is impractical to implement in > > > policy > > > currently, 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 children to the parent in policy > > > currently, and it is doubtful that doing so would be desirable even > > > if > > > it were practical, as it requires leaking permissions to objects and > > > operations into parent domains that could weaken their own security > > > in > > > order to allow them to the children (e.g. if a child requires execmem > > > permission, then so does the parent; if a child requires read to a > > > symbolic > > > link or temporary file that it can write, then so does the parent, > > > ...). > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't have to > > > make a choice between them. Introduce a new policy capability that > > > causes the ability to transition under NNP to be based on a new > > > permission > > > check 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. The rationale for > > > this > > > divergence from NNP behavior for capabilities is that SELinux > > > permissions > > > are substantially broader than just capabilities (they express a full > > > access matrix, not just privileges) and can only be used to further > > > restrict capabilities, not grant them beyond what is already > > > permitted. > > > Unit files can be left unmodified from upstream. SELinux-disabled > > > users > > > win. SELinux-enabled users can benefit from systemd-provided > > > protections > > > and policy won't need to radically change. > > > > > > This change takes the last approach above, as it seems to be the > > > best option. > > > > > > Signed-off-by: Stephen Smalley > > > --- > > > 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..f0c11c2 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 onl
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > As systemd ramps up enabling NoNewPrivileges (either explicitly > > > > in > > > > service unit files or as a side effect of other security- > > > > related > > > > settings in service unit files), we're increasingly running > > > > afoul of > > > > its interactions with SELinux. > > > > > > > > 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. > > > > > > > > Our options seem to be: > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > remove > > > > default protection settings from upstream package unit files in > > > > order > > > > to have them work with SELinux (and not just NoNewPrivileges= > > > > itself; increasingly systemd is enabling NNP as a side effect > > > > of > > > > other > > > > unit file options, even seemingly unrelated ones like > > > > PrivateDevices). > > > > SELinux-disabled users lose entirely, SELinux-enabled users may > > > > lose > > > > (depending on whether SELinux policy provides equivalent or > > > > better guarantees). > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > enabled > > > > systems. Unit files can be left unmodified from > > > > upstream. SELinux- > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > 3) Try to use typebounds, since we allow bounded transitions > > > > under > > > > NNP. > > > > Unit files can be left unmodified from upstream. SELinux- > > > > disabled > > > > users > > > > win. SELinux-enabled users get to benefit from systemd- > > > > provided > > > > protections. However, this option is impractical to implement > > > > in > > > > policy > > > > currently, 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 children to the parent in > > > > policy > > > > currently, and it is doubtful that doing so would be desirable > > > > even > > > > if > > > > it were practical, as it requires leaking permissions to > > > > objects and > > > > operations into parent domains that could weaken their own > > > > security > > > > in > > > > order to allow them to the children (e.g. if a child requires > > > > execmem > > > > permission, then so does the parent; if a child requires read > > > > to a > > > > symbolic > > > > link or temporary file that it can write, then so does the > > > > parent, > > > > ...). > > > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't have > > > > to > > > > make a choice between them. Introduce a new policy capability > > > > that > > > > causes the ability to transition under NNP to be based on a new > > > > permission > > > > check 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. The rationale > > > > for > > > > this > > > > divergence from NNP behavior for capabilities is that SELinux > > > > permissions > > > > are substantially broader than just capabilities (they express > > > > a full > > > > access matrix, not just privileges) and can only be used to > > > > further > > > > restrict capabilities, not grant them beyond what is already > > > > permitted. > > > > Unit files can be left unmodified from upstream. SELinux- > > > > disabled > > > > users > > > > win. SELinux-enabled users can benefit from systemd-provided > > > > protections > > > > and policy won't need to radically change. > > > > > > > > This change takes the last approach above, as it seems to be > > > > the > > > > best option. > > > > > > > > Signed-off-by: Stephen Smalley > > > > --- > > > > 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 insertio
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote: > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > > As systemd ramps up enabling NoNewPrivileges (either explicitly > > > > > in > > > > > service unit files or as a side effect of other security- > > > > > related > > > > > settings in service unit files), we're increasingly running > > > > > afoul of > > > > > its interactions with SELinux. > > > > > > > > > > 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. > > > > > > > > > > Our options seem to be: > > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > > remove > > > > > default protection settings from upstream package unit files in > > > > > order > > > > > to have them work with SELinux (and not just NoNewPrivileges= > > > > > itself; increasingly systemd is enabling NNP as a side effect > > > > > of > > > > > other > > > > > unit file options, even seemingly unrelated ones like > > > > > PrivateDevices). > > > > > SELinux-disabled users lose entirely, SELinux-enabled users may > > > > > lose > > > > > (depending on whether SELinux policy provides equivalent or > > > > > better guarantees). > > > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > > enabled > > > > > systems. Unit files can be left unmodified from > > > > > upstream. SELinux- > > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > > > 3) Try to use typebounds, since we allow bounded transitions > > > > > under > > > > > NNP. > > > > > Unit files can be left unmodified from upstream. SELinux- > > > > > disabled > > > > > users > > > > > win. SELinux-enabled users get to benefit from systemd- > > > > > provided > > > > > protections. However, this option is impractical to implement > > > > > in > > > > > policy > > > > > currently, 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 children to the parent in > > > > > policy > > > > > currently, and it is doubtful that doing so would be desirable > > > > > even > > > > > if > > > > > it were practical, as it requires leaking permissions to > > > > > objects and > > > > > operations into parent domains that could weaken their own > > > > > security > > > > > in > > > > > order to allow them to the children (e.g. if a child requires > > > > > execmem > > > > > permission, then so does the parent; if a child requires read > > > > > to a > > > > > symbolic > > > > > link or temporary file that it can write, then so does the > > > > > parent, > > > > > ...). > > > > > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't have > > > > > to > > > > > make a choice between them. Introduce a new policy capability > > > > > that > > > > > causes the ability to transition under NNP to be based on a new > > > > > permission > > > > > check 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. The rationale > > > > > for > > > > > this > > > > > divergence from NNP behavior for capabilities is that SELinux > > > > > permissions > > > > > are substantially broader than just capabilities (they express > > > > > a full > > > > > access matrix, not just privileges) and can only be used to > > > > > further > > > > > restrict capabilities, not grant them beyond what is already > > > > > permitted. > > > > > Unit files can be left unmodified from upstream. SELinux- > > > > > disabled > > > > > users > > > > > win. SELinux-enabled users can benefit from systemd-provided > > > > > protections > > > > > and policy won't need to radically change. > > > > > > > > > > This change takes the last approach above, as it seems to be > > > > > the > > > > > best option. > > > > > > > > > > Signed-off-by: Stephen Smalley > > > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley wrote:
> As systemd ramps up enabling NoNewPrivileges (either explicitly in
> service unit files or as a side effect of other security-related
> settings in service unit files), we're increasingly running afoul of
> its interactions with SELinux...
We already talked about this in the other thread so I'll refrain from
repeating myself.
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3a06afb..f0c11c2 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_transition policy capability,
> +* then we permit transitions under NNP or nosuid if the
> +* policy explicitly allows nnp_transition permission between
> +* the old and new contexts.
> */
> - rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
> - if (rc) {
> + if (selinux_policycap_nnptransition) {
> + rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> + SECCLASS_PROCESS,
> + PROCESS__NNP_TRANSITION, NULL);
> + if (!rc)
> + return 0;
This is interesting, we had been talking about domain transitions
under NNP, but we never really discussed transitions under nosuid
mounts, and the motivation for this patch appears to be entirely
around NNP alone.
I think the policycap/permission approach is reasonable, but I wonder
if we should separate this into two permissions, e.g. process {
nnp_transition nosuid_transition }, especially since such a change in
the future would likely require another policycap?
--
paul moore
www.paul-moore.com
