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

[Dominick Grift]

On Thu, Jul 13, 2017 at 07:55:14PM -0400, Chris PeBenito wrote:
> On 07/13/2017 04:11 PM, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > > > > wrote:
> > > > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > > > > > > > @tycho
> > > > > > > > > > > > .nsa
> > > > > > > > > > > > .gov
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > > > > Smalley  > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > ho.n
> > > > > > > > > > > > > > > sa
> > > > > > > > > > > > > > > .gov
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > > > > >  > > > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > restrictions
> > > > > > > > > > > > > > > might
> > > > > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > patch:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > > > > description.  It
> > > > > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > > > > good
> > > > > > > > > > > > > > > so we
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > NNP
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > good.
> > > > > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > > > > picking
> > > > > > > > > > > > > > > names;
> > > > > > > > > > > > > > > how
> > > > > > > > > > > > > > > about
> > > > > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > > > > "?
> > > > > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > > > > Privileges"
> > > > > > > > > > > > > > encompasses
> > > > > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > > > > separated
> > > > > > > > > > > > > > I
> > > > > > > > > > > > > > would
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > > > > them was
> > > > > > > > > > > > > > needed,
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > make
> > > > > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > > > > difference.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > > > > document
> > > > > > > > > > > > > it
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > patch description.
> > > > > > > > > > > > 
> > > > > > > > > > > 

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

[Chris PeBenito]

On 07/13/2017 04:11 PM, Dominick Grift wrote:

On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:

On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:

On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:

On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:

On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:

On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
wrote:

On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:

On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
wrote:

On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:

On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:

On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley 



wrote:

On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
wrote:

On 07/12/2017 05:38 PM, Paul Moore wrote:

On Wed, Jul 12, 2017 at 9:26 AM, Stephen
Smalley 
wrote:
On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
wrote:

On Mon, Jul 10, 2017 at 4:25 PM, Stephen
Smalley

wrote:


While I think splitting the NNP/nosuid
transition
restrictions
might
be a good idea under the new policy capability,
I'm
not
sure
it
is
worth the cost of a "process2" object class.

With that in mind, let's do two things with
this
patch:

* Mention the nosuid restrictions in the patch
description.  It
doesn't need much text, but something would be
good
so we
have
documentation in the git log.

* Let's pick a new permission name that is not
specific
to
NNP
or
nosuid.  IMHO, nnpnosuid_transition is ... less
than
good.
Unfortunately, I'm not sure I'm much better at
picking
names;
how
about
"protected_transition"?  "restricted_transition
"?
"enable_transition"?  "override_transition"?


I vote for nnp_transition anyway.  "No New
Privileges"
encompasses
nosuid in my mind.  If the two perms had been
separated
I
would
have
been inclined to allow both every time one of
them was
needed,
to
make
sure no one was surprised by the behavior
difference.


I agree; I'll keep it as nnp_transition and just
document
it
in
the
patch description.


Sorry to be a stubborn about this, but nnp_transition
makes
little
sense for the nosuid restriction.  Like it or not,
NNP has
a
concrete
meaning which is distinct from nosuid mounts.  We
don't
have to
pick
any of the permission names I tossed out, none of
those
were
very
good, but I would like to see something that takes
both NNP
and
nosuid
into account, or preferably something that doesn't
use
either
name
explicitly but still conveys the meaning.


NNP is essentially a superset of nosuid; it applies to
all
execve()
calls by the process and its descendants rather than
only to
execve()
calls on specially marked filesystems.  So I viewed it
as the
more
general term.

If that's not viable, I can't think of anything clearer
or
better
than
nnp_nosuid_transition.  That clearly links it to what
it
means
(allow
a
SELinux domain transition under NNP or nosuid).  It is
somewhat
ugly
and verbose but it is clear in what it means, which I
think
is
more
important. All of your suggestions IMHO were less clear
since
they
had
no clear linkage to either NNP or nosuid, and I
couldn't tell
from
reading the permission name what it meant.  The SELinux
domain
transition isn't protected, it isn't restricted, it
isn't
clear
what
enable_transition means versus the regular transition
or
dyntransition
permissions, and we aren't overriding a transition but
rather
allowing
one under NNP/nosuid.

The only other alternative I see is to introduce a
process2
class
and
use separate nnp_transition and nosuid_transition
permissions
(but in
practice I expect them to be both allowed or denied
together).  Note
that this will require two avtab and AVC entries for
every
domain
pair
(if we allow whichever one ends up going in the
process2
class),
so
that has an impact on policy and AVC size.  Don't
really see
that
as
worthwhile.

Other approach would be to make the nosuid transition
checks
file-
based
instead so that it would go in the file class (while
the nnp
one
would
remain in the process class), but I don't think that's
really
what we
want either.  Difference between "Can domain D1
transition
under
nosuid
 to D2?" and "Can domain D1 transition under nosuid
when
executing
file
with type T1?".


Just to be clear, we would also be separately checking
regular
transition permission between the old and new contexts on
these
transitions, so you would need both:
allow D1 D2:process transition;
allow D1 T1:file nosuid_transition;
if we took the latter approach.

So we wouldn't lose entirely on a domain-to-domain check,
but
it
would
no longer be domain-to-domain for the nosuid part.

Whereas with original approach, we end up requiring:
allow D1 D2:process transition;
allow D1 D2:process nnp_nosuid_transition; # or whatever
permission
name is used


I don't know if i understand all the ins-and-outs of the
matter
but i
think i do like the idea of differentiating between
nosuid_transition
and nnp_transition
It provides more flexibility because i might not 

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

[Paul Moore]

On Thu, Jul 13, 2017 at 11:48 AM, Stephen Smalley  wrote:
> On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
>> Sorry to be a stubborn about this, but nnp_transition makes little
>> sense for the nosuid restriction.  Like it or not, NNP has a concrete
>> meaning which is distinct from nosuid mounts.  We don't have to pick
>> any of the permission names I tossed out, none of those were very
>> good, but I would like to see something that takes both NNP and
>> nosuid
>> into account, or preferably something that doesn't use either name
>> explicitly but still conveys the meaning.
>
> NNP is essentially a superset of nosuid; it applies to all execve()
> calls by the process and its descendants rather than only to execve()
> calls on specially marked filesystems.  So I viewed it as the more
> general term.

While there is clearly similar intent behind the NNP and nosuid
restrictions, they are enabled differently and typically require
differing levels of privilege.  We currently treat them similarly from
a SELinux perspective, but from a user/admin perspective they are
quite different (as Dominick points out as well).

> If that's not viable, I can't think of anything clearer or better than
> nnp_nosuid_transition.  That clearly links it to what it means (allow a
> SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> and verbose but it is clear in what it means, which I think is more
> important.

Yes, it's ugly, but probably the only option we are all likely to agree upon.

> All of your suggestions IMHO were less clear since they had
> no clear linkage to either NNP or nosuid, and I couldn't tell from
> reading the permission name what it meant.

As I said, I wasn't in love with those either, I was just trying to
kickstart some brainstorming on the permission name.

> The only other alternative I see is to introduce a process2 class and
> use separate nnp_transition and nosuid_transition permissions ...

As mentioned earlier, I don't think this is worthy of the process2 overhead.

> Other approach would be to make the nosuid transition checks file-based
> instead so that it would go in the file class (while the nnp one would
> remain in the process class), but I don't think that's really what we
> want either.  Difference between "Can domain D1 transition under nosuid
>  to D2?" and "Can domain D1 transition under nosuid when executing file
> with type T1?".

Not a fan of this option either.

> On a separate note, I plan to cc luto on the next version of the patch
> as I suspect he will have concerns about relaxing this constraint on
> NNP and this likely requires updating Documentation/prctl/no_new_privs*
> and the man pages that describe NNP behavior.

That makes sense (both CC'ing Andy and his expected concerns).

> The other model would be to figure out a way to make the typebounds
> logic work cleanly in a manner that preserves the desired NNP/nosuid
> invariant _and_ doesn't require leaking unnecessary accesses into the
> ancestor domains that make them less secure, plus CIL support for
> automatically propagating permissions in the desired way.

We talked about this in the other thread, this would obviously be my
preferred solution, but it doesn't appear practical at the moment.
The one positive with the proposed solution in this patch is that it
doesn't prevent us from later resolving this with a clever bounded
type solution in the future.

-- 
paul moore
www.paul-moore.com

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > > > > > @tycho
> > > > > > > > > > .nsa
> > > > > > > > > > .gov
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > > Smalley  > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > ho.n
> > > > > > > > > > > > > sa
> > > > > > > > > > > > > .gov
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > > >  > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > > transition
> > > > > > > > > > > > > restrictions
> > > > > > > > > > > > > might
> > > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > not
> > > > > > > > > > > > > sure
> > > > > > > > > > > > > it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > > this
> > > > > > > > > > > > > patch:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > > description.  It
> > > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > > good
> > > > > > > > > > > > > so we
> > > > > > > > > > > > > have
> > > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > > specific
> > > > > > > > > > > > > to
> > > > > > > > > > > > > NNP
> > > > > > > > > > > > > or
> > > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > > than
> > > > > > > > > > > > > good.
> > > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > > picking
> > > > > > > > > > > > > names;
> > > > > > > > > > > > > how
> > > > > > > > > > > > > about
> > > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > > "?
> > > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > > 
> > > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > > Privileges"
> > > > > > > > > > > > encompasses
> > > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > > separated
> > > > > > > > > > > > I
> > > > > > > > > > > > would
> > > > > > > > > > > > have
> > > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > > them was
> > > > > > > > > > > > needed,
> > > > > > > > > > > > to
> > > > > > > > > > > > make
> > > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > > difference.
> > > > > > > > > > > 
> > > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > > document
> > > > > > > > > > > it
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > patch description.
> > > > > > > > > > 
> > > > > > > > > > Sorry to be a stubborn about this, but nnp_transition
> > > > > > > > > > makes
> > > > > > > > > > little
> > > > > > > > > > sense for the nosuid restriction.  Like it or not,
> > > > > > > > > > NNP has
> > > > > > > > > > a
> > > > > > > > > > concrete
> > > > > > > > > > meaning which is distinct from nosuid mounts.  We
> > > > > > > > > > don't
> > > > > > > > > > have to
> > > > > > > > > > pick
> > > > > > > > > > any of the permission names I tossed out, none of
> > > > > > > > > > those
> > > > > > > > > > were
> 

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > > .nsa
> > > > > > > .gov
> > > > > > > > 
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > > > > @tyc
> > > > > > > > > > ho.n
> > > > > > > > > > sa
> > > > > > > > > > .gov
> > > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > > >  > > > > > > > > > > > @tyc
> > > > > > > > > > > > ho
> > > > > > > > > > > > .nsa
> > > > > > > > > > > > .gov>
> > > > > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > > restrictions
> > > > > > > > > > might
> > > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > 
> > > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > > patch:
> > > > > > > > > > 
> > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > description.  It
> > > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > > so we
> > > > > > > > > > have
> > > > > > > > > > documentation in the git log.
> > > > > > > > > > 
> > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > specific
> > > > > > > > > > to
> > > > > > > > > > NNP
> > > > > > > > > > or
> > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > > good.
> > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > picking
> > > > > > > > > > names;
> > > > > > > > > > how
> > > > > > > > > > about
> > > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > 
> > > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > > encompasses
> > > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > > I
> > > > > > > > > would
> > > > > > > > > have
> > > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > > needed,
> > > > > > > > > to
> > > > > > > > > make
> > > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > > 
> > > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > > it
> > > > > > > > in
> > > > > > > > the
> > > > > > > > patch description.
> > > > > > > 
> > > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > > little
> > > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > > a
> > > > > > > concrete
> > > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > > have to
> > > > > > > pick
> > > > > > > any of the permission names I tossed out, none of those
> > > > > > > were
> > > > > > > very
> > > > > > > good, but I would like to see something that takes both NNP
> > > > > > > and
> > > > > > > nosuid
> > > > > > > into account, or preferably something that doesn't use
> > > > > > > either
> > > > > > > name
> > > > > > > explicitly but still conveys the meaning.
> > > > > > 
> > > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > > execve()
> > > > > > calls by the process and its descendants rather than only to
> > > > > > execve()
> > > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > > more
> > > > > > general term.
> > > > > > 
> > > > > > If that's not viable, I can't think of anything clearer or
> > > > > > better
> > > > > > than
> > > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > > means
> > > > > > (allow
> > > > > > a
> > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > somewhat
> > > > > > ugly
> > > > > > and verbose but it is clear in what it means, which I think
> > > > > > is
> > > > > > more
> > > > > > important. All of your suggestions IMHO were less clear since
> > > > > > they
> > > > > > had
> > > > > > no clear linkage to either NNP or nosuid, and I 

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 08:16:14PM +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > .gov
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > > > ho.n
> > > > > > > > > sa
> > > > > > > > > .gov
> > > > > > > > > > wrote:
> > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > > > > > > @tyc
> > > > > > > > > > > ho
> > > > > > > > > > > .nsa
> > > > > > > > > > > .gov>
> > > > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > restrictions
> > > > > > > > > might
> > > > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > > > sure
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > 
> > > > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > > > 
> > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > description.  It
> > > > > > > > > doesn't need much text, but something would be good so we
> > > > > > > > > have
> > > > > > > > > documentation in the git log.
> > > > > > > > > 
> > > > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > > > to
> > > > > > > > > NNP
> > > > > > > > > or
> > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > good.
> > > > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > > > names;
> > > > > > > > > how
> > > > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > 
> > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > encompasses
> > > > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > > > would
> > > > > > > > have
> > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > needed,
> > > > > > > > to
> > > > > > > > make
> > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > 
> > > > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > > > in
> > > > > > > the
> > > > > > > patch description.
> > > > > > 
> > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > little
> > > > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > > > concrete
> > > > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > > > pick
> > > > > > any of the permission names I tossed out, none of those were
> > > > > > very
> > > > > > good, but I would like to see something that takes both NNP and
> > > > > > nosuid
> > > > > > into account, or preferably something that doesn't use either
> > > > > > name
> > > > > > explicitly but still conveys the meaning.
> > > > > 
> > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > execve()
> > > > > calls by the process and its descendants rather than only to
> > > > > execve()
> > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > more
> > > > > general term.
> > > > > 
> > > > > If that's not viable, I can't think of anything clearer or better
> > > > > than
> > > > > nnp_nosuid_transition.  That clearly links it to what it means
> > > > > (allow
> > > > > a
> > > > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > > > ugly
> > > > > and verbose but it is clear in what it means, which I think is
> > > > > more
> > > > > important. All of your suggestions IMHO were less clear since
> > > > > they
> > > > > had
> > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > from
> > > > > reading the permission name what it meant.  The SELinux domain
> > > > > transition isn't protected, it isn't restricted, it isn't clear
> > > > > what
> > > > > enable_transition means versus the regular transition or
> > > > > dyntransition
> > > > > permissions, and we aren't overriding a transition but rather
> > > > > allowing
> > > > > one under NNP/nosuid.
> > > > > 
> > > > > The only other alternative I see is to introduce a process2 class
> > > > > and
> > > > > use separate nnp_transition and nosuid_transition permissions
> > > > > (but in
> > > > > practice I 

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

[Stephen Smalley]

On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > > > > @tycho
> > > > > > > > > .nsa
> > > > > > > > > .gov
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > wrote:
> > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > Smalley  > > > > > > > > > > > @tyc
> > > > > > > > > > > > ho.n
> > > > > > > > > > > > sa
> > > > > > > > > > > > .gov
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > >  > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > transition
> > > > > > > > > > > > restrictions
> > > > > > > > > > > > might
> > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > I'm
> > > > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > 
> > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > this
> > > > > > > > > > > > patch:
> > > > > > > > > > > > 
> > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > description.  It
> > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > good
> > > > > > > > > > > > so we
> > > > > > > > > > > > have
> > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > 
> > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > specific
> > > > > > > > > > > > to
> > > > > > > > > > > > NNP
> > > > > > > > > > > > or
> > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > than
> > > > > > > > > > > > good.
> > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > picking
> > > > > > > > > > > > names;
> > > > > > > > > > > > how
> > > > > > > > > > > > about
> > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > "?
> > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > 
> > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > Privileges"
> > > > > > > > > > > encompasses
> > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > separated
> > > > > > > > > > > I
> > > > > > > > > > > would
> > > > > > > > > > > have
> > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > them was
> > > > > > > > > > > needed,
> > > > > > > > > > > to
> > > > > > > > > > > make
> > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > difference.
> > > > > > > > > > 
> > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > document
> > > > > > > > > > it
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > patch description.
> > > > > > > > > 
> > > > > > > > > Sorry to be a stubborn about this, but nnp_transition
> > > > > > > > > makes
> > > > > > > > > little
> > > > > > > > > sense for the nosuid restriction.  Like it or not,
> > > > > > > > > NNP has
> > > > > > > > > a
> > > > > > > > > concrete
> > > > > > > > > meaning which is distinct from nosuid mounts.  We
> > > > > > > > > don't
> > > > > > > > > have to
> > > > > > > > > pick
> > > > > > > > > any of the permission names I tossed out, none of
> > > > > > > > > those
> > > > > > > > > were
> > > > > > > > > very
> > > > > > > > > good, but I would like to see something that takes
> > > > > > > > > both NNP
> > > > > > > > > and
> > > > > > > > > nosuid
> > > > > > > > > into account, or preferably something that doesn't
> > > > > > > > > use
> > > > > > > > > either
> > > > > > > > > 

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > > > .nsa
> > > > > > > > .gov
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > > > > > @tyc
> > > > > > > > > > > ho.n
> > > > > > > > > > > sa
> > > > > > > > > > > .gov
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > > > >  > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > ho
> > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > > > restrictions
> > > > > > > > > > > might
> > > > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > 
> > > > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > > > patch:
> > > > > > > > > > > 
> > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > description.  It
> > > > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > > > so we
> > > > > > > > > > > have
> > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > 
> > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > specific
> > > > > > > > > > > to
> > > > > > > > > > > NNP
> > > > > > > > > > > or
> > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > > > good.
> > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > picking
> > > > > > > > > > > names;
> > > > > > > > > > > how
> > > > > > > > > > > about
> > > > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > 
> > > > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > > > encompasses
> > > > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > > > I
> > > > > > > > > > would
> > > > > > > > > > have
> > > > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > > > needed,
> > > > > > > > > > to
> > > > > > > > > > make
> > > > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > > > 
> > > > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > > > it
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > patch description.
> > > > > > > > 
> > > > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > > > little
> > > > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > > > a
> > > > > > > > concrete
> > > > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > > > have to
> > > > > > > > pick
> > > > > > > > any of the permission names I tossed out, none of those
> > > > > > > > were
> > > > > > > > very
> > > > > > > > good, but I would like to see something that takes both NNP
> > > > > > > > and
> > > > > > > > nosuid
> > > > > > > > into account, or preferably something that doesn't use
> > > > > > > > either
> > > > > > > > name
> > > > > > > > explicitly but still conveys the meaning.
> > > > > > > 
> > > > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > > > execve()
> > > > > > > calls by the process and its descendants rather than only to
> > > > > > > execve()
> > > > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > > > more
> > > > > > > general term.
> > > > > > > 
> > > > > > > If that's not viable, I can't think of anything clearer or
> > > > > > > better
> > > > > > > than
> > > > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > > > means
> > > > > > > (allow
> > > > > > > a
> > > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > 

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

[Stephen Smalley]

On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > > .nsa
> > > > > > .gov
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > > > @tyc
> > > > > > > > > ho.n
> > > > > > > > > sa
> > > > > > > > > .gov
> > > > > > > > > > wrote:
> > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > wrote:
> > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > >  > > > > > > > > > > @tyc
> > > > > > > > > > > ho
> > > > > > > > > > > .nsa
> > > > > > > > > > > .gov>
> > > > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > restrictions
> > > > > > > > > might
> > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > not
> > > > > > > > > sure
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > 
> > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > patch:
> > > > > > > > > 
> > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > description.  It
> > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > so we
> > > > > > > > > have
> > > > > > > > > documentation in the git log.
> > > > > > > > > 
> > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > specific
> > > > > > > > > to
> > > > > > > > > NNP
> > > > > > > > > or
> > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > good.
> > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > picking
> > > > > > > > > names;
> > > > > > > > > how
> > > > > > > > > about
> > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > 
> > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > encompasses
> > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > I
> > > > > > > > would
> > > > > > > > have
> > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > needed,
> > > > > > > > to
> > > > > > > > make
> > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > 
> > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > it
> > > > > > > in
> > > > > > > the
> > > > > > > patch description.
> > > > > > 
> > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > little
> > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > a
> > > > > > concrete
> > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > have to
> > > > > > pick
> > > > > > any of the permission names I tossed out, none of those
> > > > > > were
> > > > > > very
> > > > > > good, but I would like to see something that takes both NNP
> > > > > > and
> > > > > > nosuid
> > > > > > into account, or preferably something that doesn't use
> > > > > > either
> > > > > > name
> > > > > > explicitly but still conveys the meaning.
> > > > > 
> > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > execve()
> > > > > calls by the process and its descendants rather than only to
> > > > > execve()
> > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > more
> > > > > general term.
> > > > > 
> > > > > If that's not viable, I can't think of anything clearer or
> > > > > better
> > > > > than
> > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > means
> > > > > (allow
> > > > > a
> > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > somewhat
> > > > > ugly
> > > > > and verbose but it is clear in what it means, which I think
> > > > > is
> > > > > more
> > > > > important. All of your suggestions IMHO were less clear since
> > > > > they
> > > > > had
> > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > from
> > > > > reading the permission name what it meant.  The SELinux
> > > > > domain
> > > > > transition isn't protected, it isn't restricted, it isn't
> > > > > clear
> > > > > what
> > > > > enable_transition means versus the regular transition or
> > > > > dyntransition
> > > > > 

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > > .gov
> > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > > ho.n
> > > > > > > > sa
> > > > > > > > .gov
> > > > > > > > > wrote:
> > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > > > > > @tyc
> > > > > > > > > > ho
> > > > > > > > > > .nsa
> > > > > > > > > > .gov>
> > > > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > restrictions
> > > > > > > > might
> > > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > > sure
> > > > > > > > it
> > > > > > > > is
> > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > 
> > > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > > 
> > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > description.  It
> > > > > > > > doesn't need much text, but something would be good so we
> > > > > > > > have
> > > > > > > > documentation in the git log.
> > > > > > > > 
> > > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > > to
> > > > > > > > NNP
> > > > > > > > or
> > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > good.
> > > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > > names;
> > > > > > > > how
> > > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > 
> > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > encompasses
> > > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > > would
> > > > > > > have
> > > > > > > been inclined to allow both every time one of them was
> > > > > > > needed,
> > > > > > > to
> > > > > > > make
> > > > > > > sure no one was surprised by the behavior difference.
> > > > > > 
> > > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > > in
> > > > > > the
> > > > > > patch description.
> > > > > 
> > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > little
> > > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > > concrete
> > > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > > pick
> > > > > any of the permission names I tossed out, none of those were
> > > > > very
> > > > > good, but I would like to see something that takes both NNP and
> > > > > nosuid
> > > > > into account, or preferably something that doesn't use either
> > > > > name
> > > > > explicitly but still conveys the meaning.
> > > > 
> > > > NNP is essentially a superset of nosuid; it applies to all
> > > > execve()
> > > > calls by the process and its descendants rather than only to
> > > > execve()
> > > > calls on specially marked filesystems.  So I viewed it as the
> > > > more
> > > > general term.
> > > > 
> > > > If that's not viable, I can't think of anything clearer or better
> > > > than
> > > > nnp_nosuid_transition.  That clearly links it to what it means
> > > > (allow
> > > > a
> > > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > > ugly
> > > > and verbose but it is clear in what it means, which I think is
> > > > more
> > > > important. All of your suggestions IMHO were less clear since
> > > > they
> > > > had
> > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > from
> > > > reading the permission name what it meant.  The SELinux domain
> > > > transition isn't protected, it isn't restricted, it isn't clear
> > > > what
> > > > enable_transition means versus the regular transition or
> > > > dyntransition
> > > > permissions, and we aren't overriding a transition but rather
> > > > allowing
> > > > one under NNP/nosuid.
> > > > 
> > > > The only other alternative I see is to introduce a process2 class
> > > > and
> > > > use separate nnp_transition and nosuid_transition permissions
> > > > (but in
> > > > practice I expect them to be both allowed or denied
> > > > together).  Note
> > > > that this will require two avtab and AVC entries for every domain
> > > > pair
> > > > (if we allow whichever one ends up going in the process2 class),
> > > > so
> > > > that has an impact on policy and AVC size.  Don't really see 

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

[Stephen Smalley]

On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > > .gov
> > > > > 
> > > > 
> > > > wrote:
> > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > > ho.n
> > > > > > > sa
> > > > > > > .gov
> > > > > > > > wrote:
> > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > > > > @tyc
> > > > > > > > > ho
> > > > > > > > > .nsa
> > > > > > > > > .gov>
> > > > > > > > > wrote:
> > > > > > > 
> > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > restrictions
> > > > > > > might
> > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > sure
> > > > > > > it
> > > > > > > is
> > > > > > > worth the cost of a "process2" object class.
> > > > > > > 
> > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > 
> > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > description.  It
> > > > > > > doesn't need much text, but something would be good so we
> > > > > > > have
> > > > > > > documentation in the git log.
> > > > > > > 
> > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > to
> > > > > > > NNP
> > > > > > > or
> > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > good.
> > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > names;
> > > > > > > how
> > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > "enable_transition"?  "override_transition"?
> > > > > > 
> > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > encompasses
> > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > would
> > > > > > have
> > > > > > been inclined to allow both every time one of them was
> > > > > > needed,
> > > > > > to
> > > > > > make
> > > > > > sure no one was surprised by the behavior difference.
> > > > > 
> > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > in
> > > > > the
> > > > > patch description.
> > > > 
> > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > little
> > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > concrete
> > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > pick
> > > > any of the permission names I tossed out, none of those were
> > > > very
> > > > good, but I would like to see something that takes both NNP and
> > > > nosuid
> > > > into account, or preferably something that doesn't use either
> > > > name
> > > > explicitly but still conveys the meaning.
> > > 
> > > NNP is essentially a superset of nosuid; it applies to all
> > > execve()
> > > calls by the process and its descendants rather than only to
> > > execve()
> > > calls on specially marked filesystems.  So I viewed it as the
> > > more
> > > general term.
> > > 
> > > If that's not viable, I can't think of anything clearer or better
> > > than
> > > nnp_nosuid_transition.  That clearly links it to what it means
> > > (allow
> > > a
> > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > ugly
> > > and verbose but it is clear in what it means, which I think is
> > > more
> > > important. All of your suggestions IMHO were less clear since
> > > they
> > > had
> > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > from
> > > reading the permission name what it meant.  The SELinux domain
> > > transition isn't protected, it isn't restricted, it isn't clear
> > > what
> > > enable_transition means versus the regular transition or
> > > dyntransition
> > > permissions, and we aren't overriding a transition but rather
> > > allowing
> > > one under NNP/nosuid.
> > > 
> > > The only other alternative I see is to introduce a process2 class
> > > and
> > > use separate nnp_transition and nosuid_transition permissions
> > > (but in
> > > practice I expect them to be both allowed or denied
> > > together).  Note
> > > that this will require two avtab and AVC entries for every domain
> > > pair
> > > (if we allow whichever one ends up going in the process2 class),
> > > so
> > > that has an impact on policy and AVC size.  Don't really see that
> > > as
> > > worthwhile.
> > > 
> > > Other approach would be to make the nosuid transition checks
> > > file-
> > > based 
> > > instead so that it would go in the file class (while the nnp one
> > > would
> > > remain in the process class), but I don't think that's really
> > > what we
> > > want either. 

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

[Dominick Grift]

On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > > >
> > > wrote:
> > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > > sa
> > > > > > .gov
> > > > > > > wrote:
> > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > > > ho
> > > > > > > > .nsa
> > > > > > > > .gov>
> > > > > > > > wrote:
> > > > > > 
> > > > > > While I think splitting the NNP/nosuid transition
> > > > > > restrictions
> > > > > > might
> > > > > > be a good idea under the new policy capability, I'm not sure
> > > > > > it
> > > > > > is
> > > > > > worth the cost of a "process2" object class.
> > > > > > 
> > > > > > With that in mind, let's do two things with this patch:
> > > > > > 
> > > > > > * Mention the nosuid restrictions in the patch
> > > > > > description.  It
> > > > > > doesn't need much text, but something would be good so we
> > > > > > have
> > > > > > documentation in the git log.
> > > > > > 
> > > > > > * Let's pick a new permission name that is not specific to
> > > > > > NNP
> > > > > > or
> > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > > > how
> > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > "enable_transition"?  "override_transition"?
> > > > > 
> > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > encompasses
> > > > > nosuid in my mind.  If the two perms had been separated I would
> > > > > have
> > > > > been inclined to allow both every time one of them was needed,
> > > > > to
> > > > > make
> > > > > sure no one was surprised by the behavior difference.
> > > > 
> > > > I agree; I'll keep it as nnp_transition and just document it in
> > > > the
> > > > patch description.
> > > 
> > > Sorry to be a stubborn about this, but nnp_transition makes little
> > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > concrete
> > > meaning which is distinct from nosuid mounts.  We don't have to
> > > pick
> > > any of the permission names I tossed out, none of those were very
> > > good, but I would like to see something that takes both NNP and
> > > nosuid
> > > into account, or preferably something that doesn't use either name
> > > explicitly but still conveys the meaning.
> > 
> > NNP is essentially a superset of nosuid; it applies to all execve()
> > calls by the process and its descendants rather than only to execve()
> > calls on specially marked filesystems.  So I viewed it as the more
> > general term.
> > 
> > If that's not viable, I can't think of anything clearer or better
> > than
> > nnp_nosuid_transition.  That clearly links it to what it means (allow
> > a
> > SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> > and verbose but it is clear in what it means, which I think is more
> > important. All of your suggestions IMHO were less clear since they
> > had
> > no clear linkage to either NNP or nosuid, and I couldn't tell from
> > reading the permission name what it meant.  The SELinux domain
> > transition isn't protected, it isn't restricted, it isn't clear what
> > enable_transition means versus the regular transition or
> > dyntransition
> > permissions, and we aren't overriding a transition but rather
> > allowing
> > one under NNP/nosuid.
> > 
> > The only other alternative I see is to introduce a process2 class and
> > use separate nnp_transition and nosuid_transition permissions (but in
> > practice I expect them to be both allowed or denied together).  Note
> > that this will require two avtab and AVC entries for every domain
> > pair
> > (if we allow whichever one ends up going in the process2 class), so
> > that has an impact on policy and AVC size.  Don't really see that as
> > worthwhile.
> > 
> > Other approach would be to make the nosuid transition checks file-
> > based 
> > instead so that it would go in the file class (while the nnp one
> > would
> > remain in the process class), but I don't think that's really what we
> > want either.  Difference between "Can domain D1 transition under
> > nosuid
> >  to D2?" and "Can domain D1 transition under nosuid when executing
> > file
> > with type T1?".
> 
> Just to be clear, we would also be separately checking regular
> transition permission between the old and new contexts on these
> transitions, so you would need both:
> allow D1 D2:process transition;
> allow D1 T1:file nosuid_transition;
> if we took the latter approach.
> 
> So we wouldn't lose entirely on a domain-to-domain check, but it would
> no 

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

[Stephen Smalley]

On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  > >
> > wrote:
> > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > > sa
> > > > > .gov
> > > > > > wrote:
> > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > > ho
> > > > > > > .nsa
> > > > > > > .gov>
> > > > > > > wrote:
> > > > > 
> > > > > While I think splitting the NNP/nosuid transition
> > > > > restrictions
> > > > > might
> > > > > be a good idea under the new policy capability, I'm not sure
> > > > > it
> > > > > is
> > > > > worth the cost of a "process2" object class.
> > > > > 
> > > > > With that in mind, let's do two things with this patch:
> > > > > 
> > > > > * Mention the nosuid restrictions in the patch
> > > > > description.  It
> > > > > doesn't need much text, but something would be good so we
> > > > > have
> > > > > documentation in the git log.
> > > > > 
> > > > > * Let's pick a new permission name that is not specific to
> > > > > NNP
> > > > > or
> > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > > how
> > > > > about "protected_transition"?  "restricted_transition"?
> > > > > "enable_transition"?  "override_transition"?
> > > > 
> > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > encompasses
> > > > nosuid in my mind.  If the two perms had been separated I would
> > > > have
> > > > been inclined to allow both every time one of them was needed,
> > > > to
> > > > make
> > > > sure no one was surprised by the behavior difference.
> > > 
> > > I agree; I'll keep it as nnp_transition and just document it in
> > > the
> > > patch description.
> > 
> > Sorry to be a stubborn about this, but nnp_transition makes little
> > sense for the nosuid restriction.  Like it or not, NNP has a
> > concrete
> > meaning which is distinct from nosuid mounts.  We don't have to
> > pick
> > any of the permission names I tossed out, none of those were very
> > good, but I would like to see something that takes both NNP and
> > nosuid
> > into account, or preferably something that doesn't use either name
> > explicitly but still conveys the meaning.
> 
> NNP is essentially a superset of nosuid; it applies to all execve()
> calls by the process and its descendants rather than only to execve()
> calls on specially marked filesystems.  So I viewed it as the more
> general term.
> 
> If that's not viable, I can't think of anything clearer or better
> than
> nnp_nosuid_transition.  That clearly links it to what it means (allow
> a
> SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> and verbose but it is clear in what it means, which I think is more
> important. All of your suggestions IMHO were less clear since they
> had
> no clear linkage to either NNP or nosuid, and I couldn't tell from
> reading the permission name what it meant.  The SELinux domain
> transition isn't protected, it isn't restricted, it isn't clear what
> enable_transition means versus the regular transition or
> dyntransition
> permissions, and we aren't overriding a transition but rather
> allowing
> one under NNP/nosuid.
> 
> The only other alternative I see is to introduce a process2 class and
> use separate nnp_transition and nosuid_transition permissions (but in
> practice I expect them to be both allowed or denied together).  Note
> that this will require two avtab and AVC entries for every domain
> pair
> (if we allow whichever one ends up going in the process2 class), so
> that has an impact on policy and AVC size.  Don't really see that as
> worthwhile.
> 
> Other approach would be to make the nosuid transition checks file-
> based 
> instead so that it would go in the file class (while the nnp one
> would
> remain in the process class), but I don't think that's really what we
> want either.  Difference between "Can domain D1 transition under
> nosuid
>  to D2?" and "Can domain D1 transition under nosuid when executing
> file
> with type T1?".

Just to be clear, we would also be separately checking regular
transition permission between the old and new contexts on these
transitions, so you would need both:
allow D1 D2:process transition;
allow D1 T1:file nosuid_transition;
if we took the latter approach.

So we wouldn't lose entirely on a domain-to-domain check, but it would
no longer be domain-to-domain for the nosuid part.

Whereas with original approach, we end up requiring:
allow D1 D2:process transition;
allow D1 D2:process nnp_nosuid_transition; # or whatever permission name is used

> 
> On a separate note, I plan to cc luto on the next version of the
> patch
> as I 

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

[Stephen Smalley]

On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley 
> wrote:
> > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > > .gov
> > > > > wrote:
> > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > > > .nsa
> > > > > > .gov>
> > > > > > wrote:
> > > > 
> > > > While I think splitting the NNP/nosuid transition restrictions
> > > > might
> > > > be a good idea under the new policy capability, I'm not sure it
> > > > is
> > > > worth the cost of a "process2" object class.
> > > > 
> > > > With that in mind, let's do two things with this patch:
> > > > 
> > > > * Mention the nosuid restrictions in the patch description.  It
> > > > doesn't need much text, but something would be good so we have
> > > > documentation in the git log.
> > > > 
> > > > * Let's pick a new permission name that is not specific to NNP
> > > > or
> > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > how
> > > > about "protected_transition"?  "restricted_transition"?
> > > > "enable_transition"?  "override_transition"?
> > > 
> > > I vote for nnp_transition anyway.  "No New Privileges"
> > > encompasses
> > > nosuid in my mind.  If the two perms had been separated I would
> > > have
> > > been inclined to allow both every time one of them was needed, to
> > > make
> > > sure no one was surprised by the behavior difference.
> > 
> > I agree; I'll keep it as nnp_transition and just document it in the
> > patch description.
> 
> Sorry to be a stubborn about this, but nnp_transition makes little
> sense for the nosuid restriction.  Like it or not, NNP has a concrete
> meaning which is distinct from nosuid mounts.  We don't have to pick
> any of the permission names I tossed out, none of those were very
> good, but I would like to see something that takes both NNP and
> nosuid
> into account, or preferably something that doesn't use either name
> explicitly but still conveys the meaning.

NNP is essentially a superset of nosuid; it applies to all execve()
calls by the process and its descendants rather than only to execve()
calls on specially marked filesystems.  So I viewed it as the more
general term.

If that's not viable, I can't think of anything clearer or better than
nnp_nosuid_transition.  That clearly links it to what it means (allow a
SELinux domain transition under NNP or nosuid).  It is somewhat ugly
and verbose but it is clear in what it means, which I think is more
important. All of your suggestions IMHO were less clear since they had
no clear linkage to either NNP or nosuid, and I couldn't tell from
reading the permission name what it meant.  The SELinux domain
transition isn't protected, it isn't restricted, it isn't clear what
enable_transition means versus the regular transition or dyntransition
permissions, and we aren't overriding a transition but rather allowing
one under NNP/nosuid.

The only other alternative I see is to introduce a process2 class and
use separate nnp_transition and nosuid_transition permissions (but in
practice I expect them to be both allowed or denied together).  Note
that this will require two avtab and AVC entries for every domain pair
(if we allow whichever one ends up going in the process2 class), so
that has an impact on policy and AVC size.  Don't really see that as
worthwhile.

Other approach would be to make the nosuid transition checks file-based 
instead so that it would go in the file class (while the nnp one would
remain in the process class), but I don't think that's really what we
want either.  Difference between "Can domain D1 transition under nosuid
 to D2?" and "Can domain D1 transition under nosuid when executing file
with type T1?".

On a separate note, I plan to cc luto on the next version of the patch
as I suspect he will have concerns about relaxing this constraint on
NNP and this likely requires updating Documentation/prctl/no_new_privs*
and the man pages that describe NNP behavior.

The other model would be to figure out a way to make the typebounds
logic work cleanly in a manner that preserves the desired NNP/nosuid
invariant _and_ doesn't require leaking unnecessary accesses into the
ancestor domains that make them less secure, plus CIL support for
automatically propagating permissions in the desired way.  But I
haven't yet come up with a way to do that.  We can do it in some cases
by creating typebounds between the object types, e.g.:
typebounds parent_t child_t;
allow child_t self:process execmem;
allow child_t child_exec_t:file entrypoint;
allow child_t child_tmp_t:file create;
can be allowed via:
allow parent_t child_t:process execmem; # an otherwise nonsensical rule
typebounds parent_exec_t 

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

[Paul Moore]

On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley  wrote:
> On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
>> On 07/12/2017 05:38 PM, Paul Moore wrote:
>> > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley > > > wrote:
>> > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
>> > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley > > > > .gov>
>> > > > wrote:
>> > While I think splitting the NNP/nosuid transition restrictions
>> > might
>> > be a good idea under the new policy capability, I'm not sure it is
>> > worth the cost of a "process2" object class.
>> >
>> > With that in mind, let's do two things with this patch:
>> >
>> > * Mention the nosuid restrictions in the patch description.  It
>> > doesn't need much text, but something would be good so we have
>> > documentation in the git log.
>> >
>> > * Let's pick a new permission name that is not specific to NNP or
>> > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
>> > Unfortunately, I'm not sure I'm much better at picking names; how
>> > about "protected_transition"?  "restricted_transition"?
>> > "enable_transition"?  "override_transition"?
>>
>> I vote for nnp_transition anyway.  "No New Privileges" encompasses
>> nosuid in my mind.  If the two perms had been separated I would have
>> been inclined to allow both every time one of them was needed, to
>> make
>> sure no one was surprised by the behavior difference.
>
> I agree; I'll keep it as nnp_transition and just document it in the
> patch description.

Sorry to be a stubborn about this, but nnp_transition makes little
sense for the nosuid restriction.  Like it or not, NNP has a concrete
meaning which is distinct from nosuid mounts.  We don't have to pick
any of the permission names I tossed out, none of those were very
good, but I would like to see something that takes both NNP and nosuid
into account, or preferably something that doesn't use either name
explicitly but still conveys the meaning.

-- 
paul moore
www.paul-moore.com

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

[Stephen Smalley]

On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> On 07/12/2017 05:38 PM, Paul Moore wrote:
> > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  > > wrote:
> > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley  > > > .gov>
> > > > wrote:
> > While I think splitting the NNP/nosuid transition restrictions
> > might
> > be a good idea under the new policy capability, I'm not sure it is
> > worth the cost of a "process2" object class.
> > 
> > With that in mind, let's do two things with this patch:
> > 
> > * Mention the nosuid restrictions in the patch description.  It
> > doesn't need much text, but something would be good so we have
> > documentation in the git log.
> > 
> > * Let's pick a new permission name that is not specific to NNP or
> > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > Unfortunately, I'm not sure I'm much better at picking names; how
> > about "protected_transition"?  "restricted_transition"?
> > "enable_transition"?  "override_transition"?
> 
> I vote for nnp_transition anyway.  "No New Privileges" encompasses 
> nosuid in my mind.  If the two perms had been separated I would have 
> been inclined to allow both every time one of them was needed, to
> make 
> sure no one was surprised by the behavior difference.

I agree; I'll keep it as nnp_transition and just document it in the
patch description.

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

[Chris PeBenito]

On 07/12/2017 05:38 PM, Paul Moore wrote:

On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  wrote:

On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:

On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley 
wrote:



While I think splitting the NNP/nosuid transition restrictions might
be a good idea under the new policy capability, I'm not sure it is
worth the cost of a "process2" object class.

With that in mind, let's do two things with this patch:

* Mention the nosuid restrictions in the patch description.  It
doesn't need much text, but something would be good so we have
documentation in the git log.

* Let's pick a new permission name that is not specific to NNP or
nosuid.  IMHO, nnpnosuid_transition is ... less than good.
Unfortunately, I'm not sure I'm much better at picking names; how
about "protected_transition"?  "restricted_transition"?
"enable_transition"?  "override_transition"?


I vote for nnp_transition anyway.  "No New Privileges" encompasses 
nosuid in my mind.  If the two perms had been separated I would have 
been inclined to allow both every time one of them was needed, to make 
sure no one was surprised by the behavior difference.



--
Chris PeBenito

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

[Paul Moore]

On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley  wrote:
> On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
>> 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.
>
> Yes, I decided to keep NNP and nosuid handling consistent.  Similar
> arguments apply; the current restriction on SELinux transitions on
> nosuid mounts forces users to make a choice between SELinux transitions
> and nosuid mounts, which can leave them less protected.  That has been
> a common issue e.g. for httpd transitions on cgi scripts and the like.

I'm not arguing that decoupling the NNP/nosuid state and SELinux
domain transitions is a bad idea, it's a good idea, I'm just thinking
that providing some additional granularity by splitting NNP and nosuid
might be a good thing.  However, the permission limitation clouds that
a bit; more below.

>> 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?
>
> I was hoping to avoid that and keep the nnp/nosuid handling consistent.
>  Also, we are out of process permissions after nnp_transition, so we
> can't do that without adding a process2 or similar class. Possibly we
> could name the capability and permission more generally to make it
> clearer that it affect both, but not sure what to suggest there
> (nnpnosuid_transition?).

While I think splitting the NNP/nosuid transition restrictions might
be a good idea under the new policy capability, I'm not sure it is
worth the cost of a "process2" object class.

With that in mind, let's do two things with this patch:

* Mention the nosuid restrictions in the patch description.  It
doesn't need much text, but something would be good so we have
documentation in the git log.

* Let's pick a new permission name that is not specific to NNP or
nosuid.  IMHO, nnpnosuid_transition is ... less than good.
Unfortunately, I'm not sure I'm much better at picking names; how
about "protected_transition"?  "restricted_transition"?
"enable_transition"?  "override_transition"?

-- 
paul moore
www.paul-moore.com

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

[Stephen Smalley]

On Wed, 2017-07-12 at 15:42 +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:38:28PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > > 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 

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

[Stephen Smalley]

On Wed, 2017-07-12 at 15:38 +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > 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
> 

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

[Dominick Grift]

On Wed, Jul 12, 2017 at 03:38:28PM +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > 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 

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

[Dominick Grift]

On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > 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
> > > > > > > > 

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

[Dominick Grift]

On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > 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
> > > > > > > 

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

[Stephen Smalley]

On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> 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.

Yes, I decided to keep NNP and nosuid handling consistent.  Similar
arguments apply; the current restriction on SELinux transitions on
nosuid mounts forces users to make a choice between SELinux transitions
and nosuid mounts, which can leave them less protected.  That has been
a common issue e.g. for httpd transitions on cgi scripts and the like.

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

I was hoping to avoid that and keep the nnp/nosuid handling consistent.
 Also, we are out of process permissions after nnp_transition, so we
can't do that without adding a process2 or similar class. Possibly we
could name the capability and permission more generally to make it
clearer that it affect both, but not sure what to suggest there
(nnpnosuid_transition?).

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

[Stephen Smalley]

On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> 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 

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

[Paul Moore]

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

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

[Dominick Grift]

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

[Stephen Smalley]

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 

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

[Dominick Grift]

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

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

[Dominick Grift]

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 

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

[Stephen Smalley]

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 = 

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

[Stephen Smalley]

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_tsec->sid,
+ SECCLASS_PROCESS,
+ PROCESS__NNP_TRANSITION, NULL);
+   if (!rc)
+   return 0;
+   } else {
/*
-*