Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Paul Moore <paul@paul-moore.com>]

On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa.gov> 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