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

2017-07-19 Thread 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

Re: [PATCH] selinux-testsuite: Add tests for AT_SECURE

2017-07-19 Thread Paul Moore 
On Wed, Jul 19, 2017 at 11:26 AM, Stephen Smalley  wrote:
> Add tests for the AT_SECURE auxv flag to ensure that its value
> is set correctly based on whether noatsecure permission is allowed
> between the old domain and the new domain.
>
> Also test that the dynamic linker ignores LD_PRELOAD when AT_SECURE
> is set to 1.
>
> AT_SECURE has been supported since Linux 2.6.0, so these tests should
> work on all SELinux systems and do not need to be conditionally enabled.
>
> Signed-off-by: Stephen Smalley 
> ---
>  policy/Makefile   |  2 +-
>  policy/test_atsecure.te   | 46 ++
>  tests/Makefile|  3 ++-
>  tests/atsecure/Makefile   |  9 +
>  tests/atsecure/atsecure.c | 10 ++
>  tests/atsecure/evil.c | 10 ++
>  tests/atsecure/good.c | 10 ++
>  tests/atsecure/test   | 31 +++
>  8 files changed, 119 insertions(+), 2 deletions(-)
>  create mode 100644 policy/test_atsecure.te
>  create mode 100644 tests/atsecure/Makefile
>  create mode 100644 tests/atsecure/atsecure.c
>  create mode 100644 tests/atsecure/evil.c
>  create mode 100644 tests/atsecure/good.c
>  create mode 100755 tests/atsecure/test

Merged, thanks.

I wanted to get this in soon so we have something to use to verify the
changes in Kees' patchset.

-- 
paul moore
www.paul-moore.com

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

2017-07-19 Thread 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

2017-07-19 Thread 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

Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions

2017-07-19 Thread Paul Moore 
On Tue, Jul 18, 2017 at 9:07 PM, 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'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.
>
> 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.

It seems that falling back to the bounded transition is the best way forward.

Sorry to make you spin another version of the patch Stephen.

-- 
paul moore
www.paul-moore.com

[PATCH] selinux-testsuite: Add tests for AT_SECURE

2017-07-19 Thread Stephen Smalley 
Add tests for the AT_SECURE auxv flag to ensure that its value
is set correctly based on whether noatsecure permission is allowed
between the old domain and the new domain.

Also test that the dynamic linker ignores LD_PRELOAD when AT_SECURE
is set to 1.

AT_SECURE has been supported since Linux 2.6.0, so these tests should
work on all SELinux systems and do not need to be conditionally enabled.

Signed-off-by: Stephen Smalley 
---
 policy/Makefile   |  2 +-
 policy/test_atsecure.te   | 46 ++
 tests/Makefile|  3 ++-
 tests/atsecure/Makefile   |  9 +
 tests/atsecure/atsecure.c | 10 ++
 tests/atsecure/evil.c | 10 ++
 tests/atsecure/good.c | 10 ++
 tests/atsecure/test   | 31 +++
 8 files changed, 119 insertions(+), 2 deletions(-)
 create mode 100644 policy/test_atsecure.te
 create mode 100644 tests/atsecure/Makefile
 create mode 100644 tests/atsecure/atsecure.c
 create mode 100644 tests/atsecure/evil.c
 create mode 100644 tests/atsecure/good.c
 create mode 100755 tests/atsecure/test

diff --git a/policy/Makefile b/policy/Makefile
index c062009..b728a9e 100644
--- a/policy/Makefile
+++ b/policy/Makefile
@@ -23,7 +23,7 @@ TARGETS = \
test_task_getsid.te test_task_setpgid.te test_task_setsched.te \
test_transition.te test_inet_socket.te test_unix_socket.te \
test_mmap.te test_overlayfs.te test_mqueue.te test_mac_admin.te \
-   test_ibpkey.te
+   test_ibpkey.te test_atsecure.te
 
 ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
 TARGETS += test_bounds.te
diff --git a/policy/test_atsecure.te b/policy/test_atsecure.te
new file mode 100644
index 000..723
--- /dev/null
+++ b/policy/test_atsecure.te
@@ -0,0 +1,46 @@
+#
+#
+# Policy for testing the setting of the
+# AT_SECURE auxv flag based on noatsecure permission
+#
+
+attribute atsecuredomain;
+
+# Domain for process that is not allowed noatsecure to the new domain.
+type test_atsecure_denied_t;
+domain_type(test_atsecure_denied_t)
+unconfined_runs_test(test_atsecure_denied_t)
+typeattribute test_atsecure_denied_t atsecuredomain;
+typeattribute test_atsecure_denied_t testdomain;
+
+# Domain for process that is allowed noatsecure to the new domain.
+type test_atsecure_allowed_t;
+domain_type(test_atsecure_allowed_t)
+unconfined_runs_test(test_atsecure_allowed_t)
+typeattribute test_atsecure_allowed_t atsecuredomain;
+typeattribute test_atsecure_allowed_t testdomain;
+
+# New domain for the process after the transition.
+type test_atsecure_newdomain_t;
+domain_type(test_atsecure_newdomain_t)
+unconfined_runs_test(test_atsecure_newdomain_t)
+typeattribute test_atsecure_newdomain_t atsecuredomain;
+typeattribute test_atsecure_newdomain_t testdomain;
+
+# Allow the domain entrypoints and transitions.
+corecmd_bin_entry_type(atsecuredomain)
+corecmd_shell_entry_type(atsecuredomain)
+corecmd_exec_bin(atsecuredomain)
+domain_entry_file(test_atsecure_newdomain_t, test_file_t)
+domain_trans(test_atsecure_denied_t, test_file_t, test_atsecure_newdomain_t)
+domain_trans(test_atsecure_allowed_t, test_file_t, test_atsecure_newdomain_t)
+allow test_atsecure_newdomain_t test_atsecure_denied_t:fd use;
+allow test_atsecure_newdomain_t test_atsecure_allowed_t:fd use;
+allow_map(atsecuredomain, test_file_t, file)
+
+# Only allow the allowed domain noatsecure permission to the
+# new domain.
+allow test_atsecure_allowed_t test_atsecure_newdomain_t:process noatsecure;
+
+# Allow all of these domains to be entered from the sysadm domain.
+userdom_sysadm_entry_spec_domtrans_to(atsecuredomain)
diff --git a/tests/Makefile b/tests/Makefile
index 369b678..f42fe7e 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -10,7 +10,8 @@ SUBDIRS:= domain_trans entrypoint execshare exectrace 
execute_no_trans \
task_setnice task_setscheduler task_getscheduler task_getsid \
task_getpgid task_setpgid file ioctl capable_file capable_net \
capable_sys dyntrans dyntrace bounds nnp mmap unix_socket inet_socket \
-   overlay checkreqprot mqueue mac_admin infiniband_pkey infiniband_endport
+   overlay checkreqprot mqueue mac_admin infiniband_pkey \
+   infiniband_endport atsecure
 
 ifeq ($(shell grep -q cap_userns $(POLDEV)/include/support/all_perms.spt && 
echo true),true)
 ifneq ($(shell ./kvercmp $$(uname -r) 4.7),-1)
diff --git a/tests/atsecure/Makefile b/tests/atsecure/Makefile
new file mode 100644
index 000..6c08055
--- /dev/null
+++ b/tests/atsecure/Makefile
@@ -0,0 +1,9 @@
+TARGETS=atsecure good evil.so
+
+all: $(TARGETS)
+
+evil.so: evil.c
+   $(CC) -shared -o $@ -fPIC $<
+
+clean:
+   rm -f $(TARGETS)
diff --git a/tests/atsecure/atsecure.c b/tests/atsecure/atsecure.c
new file mode 100644
index 000..329c124
--- /dev/null
+++ b/tests/atsecure/atsecure.c
@@ -0,0 +1,10 @@
+#include 
+#include 
+#include 
+#include 
+