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: [PATCH] Additional tests for long-time supported netlink classes

[Paul Moore]

On Thu, Jul 13, 2017 at 1:35 PM, Stephen Smalley  wrote:
> Also, I wanted to mention that this still doesn't address testing of
> the finer-grained permissions for netlink sockets, e.g.
> nlmsg_read/write/..., as noted in the open issue:
> https://github.com/SELinuxProject/selinux-testsuite/issues/17
>
> That isn't an obstacle to taking this one, but wanted to note that we
> still want to address that at some point.

Agreed.  I still think that Milos' patch is an improvement and worth
merging once the RHEL-7 are answered/resolved (your previous email).

> Also, on the kernel side, we might want to consider defining those
> permissions for more of the netlink socket classes, particularly the
> newer ones, if/where it makes sense to do so.  Or, alternatively, to
> implement support analogous to the ioctl whitelisting support for
> netlink messages so that we can do fine-grained restrictions there.

Yes, definitely.  Long term I think doing something similar to what
was done for the individual ioctls is the best solution, but I'd be
happy to accept netlink permission mapping updates in the meantime.

-- 
paul moore
www.paul-moore.com

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.

[PATCH] Additional tests for long-time supported netlink classes

[Milos Malik]

This patch contains tests for classes which are already supported for a
long time but are not tested by the selinux-testsuite yet. These tests
involve classes like: netlink_route_socket, netlink_xfrm_socket,
netlink_selinux_socket, netlink_audit_socket,
netlink_kobject_uevent_socket, netlink_connector_socket,
netlink_scsitransport_socket, netlink_fib_lookup_socket.

Signed-off-by: Milos Malik 
---
 policy/test_netlink_socket.te |  8 
 tests/netlink_socket/test | 99 ++-
 2 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/policy/test_netlink_socket.te b/policy/test_netlink_socket.te
index c852c04..aaa6e4d 100644
--- a/policy/test_netlink_socket.te
+++ b/policy/test_netlink_socket.te
@@ -40,6 +40,14 @@ netlink_socket_test(netlink_iscsi_socket)
 netlink_socket_test(netlink_netfilter_socket)
 netlink_socket_test(netlink_generic_socket)
 netlink_socket_test(netlink_crypto_socket)
+netlink_socket_test(netlink_route_socket)
+netlink_socket_test(netlink_xfrm_socket)
+netlink_socket_test(netlink_selinux_socket)
+netlink_socket_test(netlink_audit_socket)
+netlink_socket_test(netlink_kobject_uevent_socket)
+netlink_socket_test(netlink_connector_socket)
+netlink_socket_test(netlink_scsitransport_socket)
+netlink_socket_test(netlink_fib_lookup_socket)
 
 #
 # Common rules for all netlink socket class test domains.
diff --git a/tests/netlink_socket/test b/tests/netlink_socket/test
index 487edbc..cc8c2d4 100755
--- a/tests/netlink_socket/test
+++ b/tests/netlink_socket/test
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 
 use Test;
-BEGIN { plan tests => 8 }
+BEGIN { plan tests => 24 }
 
 $basedir = $0;
 $basedir =~ s|(.*)/[^/]*|$1|;
@@ -53,3 +53,100 @@ $result = system(
 "runcon -t test_no_netlink_crypto_socket_t -- $basedir/netlinkcreate crypto 
2>&1"
 );
 ok($result);
+
+# Verify that test_netlink_route_socket_t can create a NETLINK_ROUTE socket.
+$result = system(
+"runcon -t test_netlink_route_socket_t -- $basedir/netlinkcreate route 2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_route_socket_t cannot create a NETLINK_ROUTE 
socket.
+$result = system(
+"runcon -t test_no_netlink_route_socket_t -- $basedir/netlinkcreate route 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_xfrm_socket_t can create a NETLINK_XFRM socket.
+$result = system(
+"runcon -t test_netlink_xfrm_socket_t -- $basedir/netlinkcreate xfrm 2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_xfrm_socket_t cannot create a NETLINK_XFRM 
socket.
+$result = system(
+"runcon -t test_no_netlink_xfrm_socket_t -- $basedir/netlinkcreate xfrm 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_selinux_socket_t can create a NETLINK_SELINUX 
socket.
+$result = system(
+"runcon -t test_netlink_selinux_socket_t -- $basedir/netlinkcreate selinux 
2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_selinux_socket_t cannot create a NETLINK_SELINUX 
socket.
+$result = system(
+"runcon -t test_no_netlink_selinux_socket_t -- $basedir/netlinkcreate selinux 
2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_audit_socket_t can create a NETLINK_AUDIT socket.
+$result = system(
+"runcon -t test_netlink_audit_socket_t -- $basedir/netlinkcreate audit 2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_audit_socket_t cannot create a NETLINK_AUDIT 
socket.
+$result = system(
+"runcon -t test_no_netlink_audit_socket_t -- $basedir/netlinkcreate audit 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_kobject_uevent_socket_t can create a 
NETLINK_KOBJECT_UEVENT socket.
+$result = system(
+"runcon -t test_netlink_kobject_uevent_socket_t -- $basedir/netlinkcreate 
kobject_uevent 2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_kobject_uevent_socket_t cannot create a 
NETLINK_KOBJECT_UEVENT socket.
+$result = system(
+"runcon -t test_no_netlink_kobject_uevent_socket_t -- $basedir/netlinkcreate 
kobject_uevent 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_connector_socket_t can create a NETLINK_CONNECTOR 
socket.
+$result = system(
+"runcon -t test_netlink_connector_socket_t -- $basedir/netlinkcreate connector 
2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_connector_socket_t cannot create a 
NETLINK_CONNECTOR socket.
+$result = system(
+"runcon -t test_no_netlink_connector_socket_t -- $basedir/netlinkcreate 
connector 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_scsitransport_socket_t can create a 
NETLINK_SCSITRANSPORT socket.
+$result = system(
+"runcon -t test_netlink_scsitransport_socket_t -- $basedir/netlinkcreate 
scsitransport 2>&1"
+);
+ok( $result, 0 );
+
+# Verify that test_no_netlink_scsitransport_socket_t cannot create a 
NETLINK_SCSITRANSPORT socket.
+$result = system(
+"runcon -t test_no_netlink_scsitransport_socket_t -- $basedir/netlinkcreate 
scsitransport 2>&1"
+);
+ok($result);
+
+# Verify that test_netlink_fib_lookup_socket_t can create a NETLINK_FIB_LOOKUP 
socket.
+$result = system(
+"runcon -t