[SUSPICIOUS MESSAGE] Re: [SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions

[Chris PeBenito]

On 07/19/2017 05:31 PM, Dominick Grift wrote:

On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote:

On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote:

On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote:

On 07/18/2017 05:26 PM, Paul Moore wrote:

On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley  wrote:

On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote:

On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote:

On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman 
wrote:


...


Why do we want to disallow type-bounds to work even with the
capability?
it seems sensible to me to allow typebounds to transition even in
the
future. If we do then we probably dont need the policycap which
seems
less complicated.


The suggestion to continue to support bounded domain transitions
seems
reasonable to me, although we would need to worry about which check
to
do first (bounded transition or process:nnp_nosuid_transition), and
how to limit the auditing/reporting so admins are confused by the
first check failing, yet the transition still taking place.  None
of
these are unsolvable problems, but it will likely need a bit more
work.

I'm sure Stephen has some thoughts on this as well.


Others (e.g. Dominick) seemed to take the opposite view on the
earlier
RFC discussion, i.e. that we should only check the new permission if
the capability is enabled.  I specifically raised that as a question
there.

I'm willing to change it to fallback to checking for a bounded type,
but that will mean two audit messages (I don't think we can just hide
one of them) when neither is allowed.  That said, it is unlikely to
cause much confusion in practice because users typically only look
for
and pay attention to AVC messages, and anyone using audit2allow will
just end up allowing the permission, not the bounds.


As Jason noted, if we fallback to checking for a bounded type, then we
don't strictly need a policy capability for it.


It seems as though Dominick is okay with the fallback, what do the
rest of the policy folks think about that approach?


I am okay with the faillback



I'm of the opinion that changes which don't require a new policy
capability are slightly more favorable, but since one of the goals
with this change is to make policy development easier, I want to make
sure we are actually doing that.  It would appear we are, but a few
explicit nods from the policy folks would be nice to see.


With my coder hat on, I can see the value of having the existing behavior be
available for anyone who currently uses it, so it makes sense.


I agree, its only that I believe that no one is using it because it is 
impractical (except for mod_selinux users, and people that currently use 
type_bounds to deal with nosuid),, mainly because the nnp flag is inherited.
The only scenario currently where, I believe, type_bounds might be prefered is 
containers since container process types do not change and the inheritance 
aspect is not much of a problem.



With my policy hat on, I don't have an opinion on a fallback.  What I do
know is I don't like typebounds, avoid it as much as possible, and strongly
prefer it not be forced on me.  There are no typebounds in refpolicy.

In fact, I think NNP should not affecting SELinux at all as NNP is
discretionary and SELinux is mandatory.  NNP makes sense where you start out
with lots of privileges and have to shed them, (i.e. the Linux
DAC/capabilities perspective) whereas you have no privileges in SELinux
except what is explicitly allowed.

Once this permission is implemented I'll likely add the permission across
most if not all transitions out of systemd.


Yes but do not expect that to ,always, be enough due to the inheritance aspect. 
A process may have inherited the NNP flag, not because its started by systemd 
but because its started by a process that inherited the NNP flag because it was 
started by systemd.


That just makes me want to apply the permission to all transitions for 
all domains.  Not that I'm planning to do it in refpolicy.  I'm 
definitely inclined to be very liberal in applying the permission in 
refpolicy.  For my personal systems, I'd probably do an:


allow domain domain:process nnp_nosuid_transition;

so I don't ever have to think about it again.

--
Chris PeBenito

[SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions

[Dominick Grift]

On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote:
> On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote:
> > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote:
> > > On 07/18/2017 05:26 PM, Paul Moore wrote:
> > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley  
> > > > wrote:
> > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote:
> > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote:
> > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman 
> > > > > > > 
> > > > > > > wrote:
> > > > 
> > > > ...
> > > > 
> > > > > > > > Why do we want to disallow type-bounds to work even with the
> > > > > > > > capability?
> > > > > > > > it seems sensible to me to allow typebounds to transition even 
> > > > > > > > in
> > > > > > > > the
> > > > > > > > future. If we do then we probably dont need the policycap which
> > > > > > > > seems
> > > > > > > > less complicated.
> > > > > > > 
> > > > > > > The suggestion to continue to support bounded domain transitions
> > > > > > > seems
> > > > > > > reasonable to me, although we would need to worry about which 
> > > > > > > check
> > > > > > > to
> > > > > > > do first (bounded transition or process:nnp_nosuid_transition), 
> > > > > > > and
> > > > > > > how to limit the auditing/reporting so admins are confused by the
> > > > > > > first check failing, yet the transition still taking place.  None
> > > > > > > of
> > > > > > > these are unsolvable problems, but it will likely need a bit more
> > > > > > > work.
> > > > > > > 
> > > > > > > I'm sure Stephen has some thoughts on this as well.
> > > > > > 
> > > > > > Others (e.g. Dominick) seemed to take the opposite view on the
> > > > > > earlier
> > > > > > RFC discussion, i.e. that we should only check the new permission if
> > > > > > the capability is enabled.  I specifically raised that as a question
> > > > > > there.
> > > > > > 
> > > > > > I'm willing to change it to fallback to checking for a bounded type,
> > > > > > but that will mean two audit messages (I don't think we can just 
> > > > > > hide
> > > > > > one of them) when neither is allowed.  That said, it is unlikely to
> > > > > > cause much confusion in practice because users typically only look
> > > > > > for
> > > > > > and pay attention to AVC messages, and anyone using audit2allow will
> > > > > > just end up allowing the permission, not the bounds.
> > > > > 
> > > > > As Jason noted, if we fallback to checking for a bounded type, then we
> > > > > don't strictly need a policy capability for it.
> > > > 
> > > > It seems as though Dominick is okay with the fallback, what do the
> > > > rest of the policy folks think about that approach?
> > 
> > I am okay with the faillback
> > 
> > > > 
> > > > I'm of the opinion that changes which don't require a new policy
> > > > capability are slightly more favorable, but since one of the goals
> > > > with this change is to make policy development easier, I want to make
> > > > sure we are actually doing that.  It would appear we are, but a few
> > > > explicit nods from the policy folks would be nice to see.
> > > 
> > > With my coder hat on, I can see the value of having the existing behavior 
> > > be
> > > available for anyone who currently uses it, so it makes sense.
> > 
> > I agree, its only that I believe that no one is using it because it is 
> > impractical (except for mod_selinux users, and people that currently use 
> > type_bounds to deal with nosuid),, mainly because the nnp flag is inherited.
> > The only scenario currently where, I believe, type_bounds might be prefered 
> > is containers since container process types do not change and the 
> > inheritance aspect is not much of a problem.
> > 
> > > 
> > > With my policy hat on, I don't have an opinion on a fallback.  What I do
> > > know is I don't like typebounds, avoid it as much as possible, and 
> > > strongly
> > > prefer it not be forced on me.  There are no typebounds in refpolicy.
> > > 
> > > In fact, I think NNP should not affecting SELinux at all as NNP is
> > > discretionary and SELinux is mandatory.  NNP makes sense where you start 
> > > out
> > > with lots of privileges and have to shed them, (i.e. the Linux
> > > DAC/capabilities perspective) whereas you have no privileges in SELinux
> > > except what is explicitly allowed.
> > > 
> > > Once this permission is implemented I'll likely add the permission across
> > > most if not all transitions out of systemd.
> > 
> > Yes but do not expect that to ,always, be enough due to the inheritance 
> > aspect. A process may have inherited the NNP flag, not because its started 
> > by systemd but because its started by a process that inherited the NNP flag 
> > because it was started by systemd.
> 
> In dssp2 i have this concept called forked subject types, basically these are 
> systemd daemons *and* any processes types transitioned to by systemd daemons.
> 
> These are 

[SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions

[Dominick Grift]

On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote:
> On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote:
> > On 07/18/2017 05:26 PM, Paul Moore wrote:
> > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley  
> > > wrote:
> > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote:
> > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote:
> > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman 
> > > > > > wrote:
> > > 
> > > ...
> > > 
> > > > > > > Why do we want to disallow type-bounds to work even with the
> > > > > > > capability?
> > > > > > > it seems sensible to me to allow typebounds to transition even in
> > > > > > > the
> > > > > > > future. If we do then we probably dont need the policycap which
> > > > > > > seems
> > > > > > > less complicated.
> > > > > > 
> > > > > > The suggestion to continue to support bounded domain transitions
> > > > > > seems
> > > > > > reasonable to me, although we would need to worry about which check
> > > > > > to
> > > > > > do first (bounded transition or process:nnp_nosuid_transition), and
> > > > > > how to limit the auditing/reporting so admins are confused by the
> > > > > > first check failing, yet the transition still taking place.  None
> > > > > > of
> > > > > > these are unsolvable problems, but it will likely need a bit more
> > > > > > work.
> > > > > > 
> > > > > > I'm sure Stephen has some thoughts on this as well.
> > > > > 
> > > > > Others (e.g. Dominick) seemed to take the opposite view on the
> > > > > earlier
> > > > > RFC discussion, i.e. that we should only check the new permission if
> > > > > the capability is enabled.  I specifically raised that as a question
> > > > > there.
> > > > > 
> > > > > I'm willing to change it to fallback to checking for a bounded type,
> > > > > but that will mean two audit messages (I don't think we can just hide
> > > > > one of them) when neither is allowed.  That said, it is unlikely to
> > > > > cause much confusion in practice because users typically only look
> > > > > for
> > > > > and pay attention to AVC messages, and anyone using audit2allow will
> > > > > just end up allowing the permission, not the bounds.
> > > > 
> > > > As Jason noted, if we fallback to checking for a bounded type, then we
> > > > don't strictly need a policy capability for it.
> > > 
> > > It seems as though Dominick is okay with the fallback, what do the
> > > rest of the policy folks think about that approach?
> 
> I am okay with the faillback
> 
> > > 
> > > I'm of the opinion that changes which don't require a new policy
> > > capability are slightly more favorable, but since one of the goals
> > > with this change is to make policy development easier, I want to make
> > > sure we are actually doing that.  It would appear we are, but a few
> > > explicit nods from the policy folks would be nice to see.
> > 
> > With my coder hat on, I can see the value of having the existing behavior be
> > available for anyone who currently uses it, so it makes sense.
> 
> I agree, its only that I believe that no one is using it because it is 
> impractical (except for mod_selinux users, and people that currently use 
> type_bounds to deal with nosuid),, mainly because the nnp flag is inherited.
> The only scenario currently where, I believe, type_bounds might be prefered 
> is containers since container process types do not change and the inheritance 
> aspect is not much of a problem.
> 
> > 
> > With my policy hat on, I don't have an opinion on a fallback.  What I do
> > know is I don't like typebounds, avoid it as much as possible, and strongly
> > prefer it not be forced on me.  There are no typebounds in refpolicy.
> > 
> > In fact, I think NNP should not affecting SELinux at all as NNP is
> > discretionary and SELinux is mandatory.  NNP makes sense where you start out
> > with lots of privileges and have to shed them, (i.e. the Linux
> > DAC/capabilities perspective) whereas you have no privileges in SELinux
> > except what is explicitly allowed.
> > 
> > Once this permission is implemented I'll likely add the permission across
> > most if not all transitions out of systemd.
> 
> Yes but do not expect that to ,always, be enough due to the inheritance 
> aspect. A process may have inherited the NNP flag, not because its started by 
> systemd but because its started by a process that inherited the NNP flag 
> because it was started by systemd.

In dssp2 i have this concept called forked subject types, basically these are 
systemd daemons *and* any processes types transitioned to by systemd daemons.

These are rules specific for systemd (system) forked subject types*:

[root@julius ~]# sesearch -A -t systemd.system.forked_subj_type_attribute -dt
allow systemd.system.subj systemd.system.forked_subj_type_attribute:process { 
getsched setrlimit setsched };

[root@julius ~]# sesearch -A -s systemd.system.forked_subj_type_attribute -ds
allow