[RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

A long time ago, before the secid reconciliation "fun" the SELinux/NetLabel glue
code made use of SECINITSID_NETMSG as the basis for the TE portion of
the context when there was none to be had in the incoming packet's security
attributes (i.e. when using CIPSO).  This worked well enough, but then the
secid reconciliation effort came along and it wanted to use the NETMSG initial
SID so NetLabel was changed to use the UNLABELED initial SID (there were other
arguments as well, search the archives if interested).  This change was
invisibile to users since policy by default assigns both the NETMSG and
UNLABELED intitial SIDs the "unlabeled_t" type.

Well, the secid reconciliation effort died a painful death but the SELinux
NetLabel support continued to use the UNLABELED initial SID.  At first glance
this may not appear to be a very big deal but it does have some implications
which are not very pretty.  The main problem is that it is currently impossible
to have a SELinux access check for an unlabeled packet using the 
{tcp,udp,rawip}_socket:recvfrom permission.  Why is that?  The reason is that
the SELinux/NetLabel glue code has to use SECINITSID_UNLABELED as a base which
means that NetLabel'd packets look exactly like normal unlabeled objects on the
system (although they have different MLS sensitivity labels).  Using
SECINITSID_UNLABELED does not give us any alternate type to use for packets
without NetLabel security attributes since we already using that type for
packets with NetLabel security attributes.  As a result the NetLabel access
check is only done when NetLabel security attributes are present.

I'm proposing two changes to the existing SELinux/NetLabel glue code:

1. Switch to using SECINITSID_NETMSG for packets with NetLabel security
   attributes
2. Add a unlabeled check for packets without NetLabel security attributes
   using SECINITSID_UNLABELED

These two changes will make NetLabel behave like labeled IPsec where there is
an access check for both labeled and unlabeled packets as well as providing us
with the ability to restrict domains to receiving only labeled packets when
NetLabel is in use.  The changes to the policy would be straight forward with
the following necessary to receive labeled traffic (assuming SECINITSID_NETMSG
is defined to use "netlabel_t"):

 allow mydomain_t netlabel_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

The policy for unlabeled traffic would be:

 allow mydomain_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

NOTE: The patch below is backed against a current-ish snapshot of the net-2.6
git tree, there are patched pending that would require this to be rebased.
Also, this really, truly is a RFC patch, I've only compile-tested these
changes.  Please feel free to comment on them but don't try to apply them and
expect everything to work ;)

---
 security/selinux/hooks.c            |    8 +++-----
 security/selinux/include/security.h |    2 +-
 security/selinux/ss/services.c      |   11 +++++------
 3 files changed, 9 insertions(+), 12 deletions(-)

Index: net-2.6_netmsg/security/selinux/hooks.c
===================================================================
--- net-2.6_netmsg.orig/security/selinux/hooks.c
+++ net-2.6_netmsg/security/selinux/hooks.c
@@ -3664,9 +3664,7 @@ static int selinux_socket_getpeersec_dgr
 	if (sock && sock->sk->sk_family == PF_UNIX)
 		selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid);
 	else if (skb)
-		security_skb_extlbl_sid(skb,
-					SECINITSID_UNLABELED,
-					&peer_secid);
+		security_skb_extlbl_sid(skb, &peer_secid);
 
 	if (peer_secid == SECSID_NULL)
 		err = -EINVAL;
@@ -3727,7 +3725,7 @@ static int selinux_inet_conn_request(str
 	u32 newsid;
 	u32 peersid;
 
-	security_skb_extlbl_sid(skb, SECINITSID_UNLABELED, &peersid);
+	security_skb_extlbl_sid(skb, &peersid);
 	if (peersid == SECSID_NULL) {
 		req->secid = sksec->sid;
 		req->peer_secid = SECSID_NULL;
@@ -3765,7 +3763,7 @@ static void selinux_inet_conn_establishe
 {
 	struct sk_security_struct *sksec = sk->sk_security;
 
-	security_skb_extlbl_sid(skb, SECINITSID_UNLABELED, &sksec->peer_sid);
+	security_skb_extlbl_sid(skb, &sksec->peer_sid);
 }
 
 static void selinux_req_classify_flow(const struct request_sock *req,
Index: net-2.6_netmsg/security/selinux/include/security.h
===================================================================
--- net-2.6_netmsg.orig/security/selinux/include/security.h
+++ net-2.6_netmsg/security/selinux/include/security.h
@@ -82,7 +82,7 @@ int security_netif_sid(char *name, u32 *
 int security_node_sid(u16 domain, void *addr, u32 addrlen,
 	u32 *out_sid);
 
-void security_skb_extlbl_sid(struct sk_buff *skb, u32 base_sid, u32 *sid);
+void security_skb_extlbl_sid(struct sk_buff *skb, u32 *sid);
 
 int security_validate_transition(u32 oldsid, u32 newsid, u32 tasksid,
                                  u16 tclass);
Index: net-2.6_netmsg/security/selinux/ss/services.c
===================================================================
--- net-2.6_netmsg.orig/security/selinux/ss/services.c
+++ net-2.6_netmsg/security/selinux/ss/services.c
@@ -2201,7 +2201,6 @@ void selinux_audit_set_callback(int (*ca
 /**
  * security_skb_extlbl_sid - Determine the external label of a packet
  * @skb: the packet
- * @base_sid: the SELinux SID to use as a context for MLS only external labels
  * @sid: the packet's SID
  *
  * Description:
@@ -2209,7 +2208,7 @@ void selinux_audit_set_callback(int (*ca
  * the external SID for the packet.
  *
  */
-void security_skb_extlbl_sid(struct sk_buff *skb, u32 base_sid, u32 *sid)
+void security_skb_extlbl_sid(struct sk_buff *skb, u32 *sid)
 {
 	u32 xfrm_sid;
 	u32 nlbl_sid;
@@ -2217,7 +2216,7 @@ void security_skb_extlbl_sid(struct sk_b
 	selinux_skb_xfrm_sid(skb, &xfrm_sid);
 	if (selinux_netlbl_skbuff_getsid(skb,
 					 (xfrm_sid == SECSID_NULL ?
-					  base_sid : xfrm_sid),
+					  SECINITSID_NETMSG : xfrm_sid),
 					 &nlbl_sid) != 0)
 		nlbl_sid = SECSID_NULL;
 
@@ -2623,7 +2622,7 @@ void selinux_netlbl_sock_graft(struct so
 	    secattr.flags != NETLBL_SECATTR_NONE &&
 	    selinux_netlbl_secattr_to_sid(NULL,
 					  &secattr,
-					  SECINITSID_UNLABELED,
+					  SECINITSID_NETMSG,
 					  &nlbl_peer_sid) == 0)
 		sksec->peer_sid = nlbl_peer_sid;
 	netlbl_secattr_destroy(&secattr);
@@ -2696,13 +2695,13 @@ int selinux_netlbl_sock_rcv_skb(struct s
 	u32 recv_perm;
 
 	rc = selinux_netlbl_skbuff_getsid(skb,
-					  SECINITSID_UNLABELED,
+					  SECINITSID_NETMSG,
 					  &netlbl_sid);
 	if (rc != 0)
 		return rc;
 
 	if (netlbl_sid == SECSID_NULL)
-		return 0;
+		netlbl_sid = SECINITSID_UNLABELED;
 
 	switch (sksec->sclass) {
 	case SECCLASS_UDP_SOCKET:

--
paul moore
linux security @ hp


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Joshua Brindle]

Paul Moore wrote:
> A long time ago, before the secid reconciliation "fun" the SELinux/NetLabel glue
> code made use of SECINITSID_NETMSG as the basis for the TE portion of
> the context when there was none to be had in the incoming packet's security
> attributes (i.e. when using CIPSO).  This worked well enough, but then the
> secid reconciliation effort came along and it wanted to use the NETMSG initial
> SID so NetLabel was changed to use the UNLABELED initial SID (there were other
> arguments as well, search the archives if interested).  This change was
> invisibile to users since policy by default assigns both the NETMSG and
> UNLABELED intitial SIDs the "unlabeled_t" type.
>
> Well, the secid reconciliation effort died a painful death but the SELinux
> NetLabel support continued to use the UNLABELED initial SID.  At first glance
> this may not appear to be a very big deal but it does have some implications
> which are not very pretty.  The main problem is that it is currently impossible
> to have a SELinux access check for an unlabeled packet using the 
> {tcp,udp,rawip}_socket:recvfrom permission.  Why is that?  The reason is that
> the SELinux/NetLabel glue code has to use SECINITSID_UNLABELED as a base which
> means that NetLabel'd packets look exactly like normal unlabeled objects on the
> system (although they have different MLS sensitivity labels).  Using
> SECINITSID_UNLABELED does not give us any alternate type to use for packets
> without NetLabel security attributes since we already using that type for
> packets with NetLabel security attributes.  As a result the NetLabel access
> check is only done when NetLabel security attributes are present.
>
> I'm proposing two changes to the existing SELinux/NetLabel glue code:
>
> 1. Switch to using SECINITSID_NETMSG for packets with NetLabel security
>    attributes
> 2. Add a unlabeled check for packets without NetLabel security attributes
>    using SECINITSID_UNLABELED
>
> These two changes will make NetLabel behave like labeled IPsec where there is
> an access check for both labeled and unlabeled packets as well as providing us
> with the ability to restrict domains to receiving only labeled packets when
> NetLabel is in use.  The changes to the policy would be straight forward with
> the following necessary to receive labeled traffic (assuming SECINITSID_NETMSG
> is defined to use "netlabel_t"):
>
>  allow mydomain_t netlabel_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
>
> The policy for unlabeled traffic would be:
>
>  allow mydomain_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
>
>   

this is semi-hacky since the user, role and type parts of a netmsg label 
really are unlabeled (eg., there isn't a label present so they are 
unlabeled) but the effect of treating them that way is unfortunate, I'll 
agree. Given that it isn't possible to treat completely unlabeled 
packets and partially labeled packets differently without this I think 
its probably necessary.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Stephen Smalley]

On Tue, 2007-03-13 at 22:50 -0400, Paul Moore wrote:
> plain text document attachment (selinux-netlabel_netmsg_initsid)
> A long time ago, before the secid reconciliation "fun" the SELinux/NetLabel glue
> code made use of SECINITSID_NETMSG as the basis for the TE portion of
> the context when there was none to be had in the incoming packet's security
> attributes (i.e. when using CIPSO).  This worked well enough, but then the
> secid reconciliation effort came along and it wanted to use the NETMSG initial
> SID so NetLabel was changed to use the UNLABELED initial SID (there were other
> arguments as well, search the archives if interested).  This change was
> invisibile to users since policy by default assigns both the NETMSG and
> UNLABELED intitial SIDs the "unlabeled_t" type.
> 
> Well, the secid reconciliation effort died a painful death but the SELinux
> NetLabel support continued to use the UNLABELED initial SID.  At first glance
> this may not appear to be a very big deal but it does have some implications
> which are not very pretty.  The main problem is that it is currently impossible
> to have a SELinux access check for an unlabeled packet using the 
> {tcp,udp,rawip}_socket:recvfrom permission.  Why is that?  The reason is that
> the SELinux/NetLabel glue code has to use SECINITSID_UNLABELED as a base which
> means that NetLabel'd packets look exactly like normal unlabeled objects on the
> system (although they have different MLS sensitivity labels).  Using
> SECINITSID_UNLABELED does not give us any alternate type to use for packets
> without NetLabel security attributes since we already using that type for
> packets with NetLabel security attributes.  As a result the NetLabel access
> check is only done when NetLabel security attributes are present.
> 
> I'm proposing two changes to the existing SELinux/NetLabel glue code:
> 
> 1. Switch to using SECINITSID_NETMSG for packets with NetLabel security
>    attributes
> 2. Add a unlabeled check for packets without NetLabel security attributes
>    using SECINITSID_UNLABELED

If you applied the second change without the first, you could
potentially distinguish the checks based on level by assigning a unique
level to the unlabeled initial SID that dominates all levels that can be
legitimately received in labeled packets.  I take it that you don't see
that as practical?

> These two changes will make NetLabel behave like labeled IPsec where there is
> an access check for both labeled and unlabeled packets as well as providing us
> with the ability to restrict domains to receiving only labeled packets when
> NetLabel is in use.  The changes to the policy would be straight forward with
> the following necessary to receive labeled traffic (assuming SECINITSID_NETMSG
> is defined to use "netlabel_t"):
> 
>  allow mydomain_t netlabel_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
> 
> The policy for unlabeled traffic would be:
> 
>  allow mydomain_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

Have you thought through the compatibility issues for old kernel / new
policy and new kernel / old policy pairings?  Also, note that policy
reload won't alter the initial SID mappings, so those will only get
updated upon reboot.  So you could have kernel with old initial SID
mappings but new allow rules effective.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

On Monday 19 March 2007 3:03:26 pm Stephen Smalley wrote:
> On Tue, 2007-03-13 at 22:50 -0400, Paul Moore wrote:
> > I'm proposing two changes to the existing SELinux/NetLabel glue code:
> >
> > 1. Switch to using SECINITSID_NETMSG for packets with NetLabel security
> >    attributes
> > 2. Add a unlabeled check for packets without NetLabel security attributes
> >    using SECINITSID_UNLABELED
>
> If you applied the second change without the first, you could
> potentially distinguish the checks based on level by assigning a unique
> level to the unlabeled initial SID that dominates all levels that can be
> legitimately received in labeled packets.  I take it that you don't see
> that as practical?

Yes, while it is both simple and tempting I don't see that solution as viable 
since it requires encoding meaning into the MLS sensitivity labels.  I 
understand that in certain other MLS implementations specific sensitivity 
labels have been given "special" meaning but I think doing so in an 
implementation as flexible as SELinux is a mistake.

> > ... The changes to the policy would
> > be straight forward with the following necessary to receive labeled
> > traffic (assuming SECINITSID_NETMSG is defined to use "netlabel_t"):
> >
> >  allow mydomain_t netlabel_t:{ tcp_socket udp_socket rawip_socket }
> > recvfrom;
> >
> > The policy for unlabeled traffic would be:
> >
> >  allow mydomain_t unlabeled_t:{ tcp_socket udp_socket rawip_socket }
> > recvfrom;
>
> Have you thought through the compatibility issues for old kernel / new
> policy and new kernel / old policy pairings?  Also, note that policy
> reload won't alter the initial SID mappings, so those will only get
> updated upon reboot.  So you could have kernel with old initial SID
> mappings but new allow rules effective.

I have given some passing thought to this, but I'll admit to not having 
solutions for every angle of this ... yet.  I posted this as an RFC patch 
because before I put to much effort into this I wanted to make sure the basic 
idea was acceptable to the community at large.  So far only you and Joshua 
have responded and while Joshua didn't seem to be too excited by it, he did 
appear to understand the need for such a change.  Assuming the compatibility 
issues can be resolved, would you be in favor of such a change?  I ask 
because from what I heard last week you are _always_ right ;)

To get back to the compatibility question, current policy gives unrestricted 
access to NetLabel (this may only be in RHEL5 right now but Dan Walsh said he 
will be submitting the upstream [add Dan to the CC line]):

 allow domains unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

So in the worst case of a new policy on an old kernel, rebooted with a newly 
defined SECINITSID_NETMSG value only domains which are only allowed to 
receive NetLabel traffic will be blocked.  I consider this acceptable as it 
is likely that anyone wishing to restrict domains only to labeled traffic 
will want to upgrade to a kernel which supports this functionality.

Like I said, it still needs more thought, i.e. all the combinations need to be 
evaluated, but I think it should be doable.  If all else fails, we would need 
to put a little more effort into solving RH BZ #195238 and then make use of 
this new functionality to toggle a compatibility mode.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Stephen Smalley]

On Tue, 2007-03-20 at 13:58 -0400, Paul Moore wrote:
> Yes, while it is both simple and tempting I don't see that solution as viable 
> since it requires encoding meaning into the MLS sensitivity labels.  I 
> understand that in certain other MLS implementations specific sensitivity 
> labels have been given "special" meaning but I think doing so in an 
> implementation as flexible as SELinux is a mistake.

I wasn't actually suggesting any special or fixed meaning for a
particular label value in the code, just assigning the unlabeled SID a
level that dominates all of the levels that are legitimate for the
system in policy (which is actually what current policy does - unlabeled
sid is mapped to mls_systemhigh definition in refpolicy), and then using
the ordinary MLS logic to ensure that packets with such a level cannot
be received without network MLS overrides.  Then any non-MLS-privileged
application would be denied access to such "unlabeled" packets, vs. the
netlabel'd packets that would have a MLS value < systemhigh.  Same
situation as for unlabeled filesystems - they have to be treated as
systemhigh under MLS.  So what is your goal?  Do you want to allow
non-netlabel'd packets under MLS (problematic then to use unlabeled SID
as the basis) or deny it?

> I have given some passing thought to this, but I'll admit to not having 
> solutions for every angle of this ... yet.  I posted this as an RFC patch 
> because before I put to much effort into this I wanted to make sure the basic 
> idea was acceptable to the community at large.  So far only you and Joshua 
> have responded and while Joshua didn't seem to be too excited by it, he did 
> appear to understand the need for such a change.  Assuming the compatibility 
> issues can be resolved, would you be in favor of such a change?  I ask 
> because from what I heard last week you are _always_ right ;)

Depends on whether it actually solves the problem any better than what
we have currently.  And I'm not always right, no matter what Karl
says ;)

> To get back to the compatibility question, current policy gives unrestricted 
> access to NetLabel (this may only be in RHEL5 right now but Dan Walsh said he 
> will be submitting the upstream [add Dan to the CC line]):
> 
>  allow domains unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
> 
> So in the worst case of a new policy on an old kernel, rebooted with a newly 
> defined SECINITSID_NETMSG value only domains which are only allowed to 
> receive NetLabel traffic will be blocked.  I consider this acceptable as it 
> is likely that anyone wishing to restrict domains only to labeled traffic 
> will want to upgrade to a kernel which supports this functionality.

IIUC, old/existing kernels skip the check altogether for non-netlabel'd
traffic and apply the check with a context derived from base SID
SECINITSID_UNLABELED (plus netlabel MLS value) for netlabel'd traffic,
and old/existing policy allows the check for unlabeled_t (if the MLS
constraint passes on the MLS value).  New kernels would always apply the
check, using SECINITSID_UNLABELED for non-netlabel'd traffic and a
context derived from base SID SECINITSID_NETMSG (plus netlabel MLS
value) for netlabel'd traffic, allowing the check for netlabel_t (if the
MLS constraint passes).  What would new policy do for unlabeled_t with
SystemHigh?  I'd expect the check to fail in that case even if you allow
it in the TE policy due to the MLS constraints except for processes with
MLS overrides.

So as I see it, the situation would be:
1) old kernel / new policy - still no checking of non-netlabel'd
traffic, and checks for netlabel'd traffic will still be based on
SECINITSID_UNLABELED, so it depends on what is allowed for unlabeled_t
in new policy - possibly no breakage here,
2) new kernel / old policy - checks for non-netlabel'd traffic will be
against SECINITSID_UNLABELED (TE allowed, MLS denied except for
processes with MLS overrides), checks for netlabel'd traffic will be
against SECINITSID_NETMSG but will end up mapping to the unlabeled
context still in the old policy, so likely TE allowed and MLS will
depend on the particular value in the packet.  Here I expect breakage
from the denials on non-netlabel'd traffic.
3) new kernel / old policy -> new policy on reload - if the new policy
drops access to unlabeled_t, then in this scenario we will end up
denying access on all traffic since the initial SIDs won't be remapped
until reboot.

> Like I said, it still needs more thought, i.e. all the combinations need to be 
> evaluated, but I think it should be doable.  If all else fails, we would need 
> to put a little more effort into solving RH BZ #195238 and then make use of 
> this new functionality to toggle a compatibility mode.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

On Tuesday 20 March 2007 2:43:31 pm Stephen Smalley wrote:
> On Tue, 2007-03-20 at 13:58 -0400, Paul Moore wrote:
> > Yes, while it is both simple and tempting I don't see that solution as
> > viable since it requires encoding meaning into the MLS sensitivity
> > labels.  I understand that in certain other MLS implementations specific
> > sensitivity labels have been given "special" meaning but I think doing so
> > in an implementation as flexible as SELinux is a mistake.
>
> I wasn't actually suggesting any special or fixed meaning for a
> particular label value in the code, just assigning the unlabeled SID a
> level that dominates all of the levels that are legitimate for the
> system in policy (which is actually what current policy does - unlabeled
> sid is mapped to mls_systemhigh definition in refpolicy), and then using
> the ordinary MLS logic to ensure that packets with such a level cannot
> be received without network MLS overrides.  Then any non-MLS-privileged
> application would be denied access to such "unlabeled" packets, vs. the
> netlabel'd packets that would have a MLS value < systemhigh.

I think by creating a sensitivity label that dominates every other label on 
the system, i.e. SystemHigh, and then restricting that label from being used 
by the network does in fact grant some special meaning to that label.  
Perhaps I'm using the wrong terminology but the point I am trying to make is 
that I would prefer to see NetLabel have the ability to support every 
sensitivity label on the system (granted some protocols may impose their own 
restrictions but others do not).

> So what is your goal?  Do you want to allow
> non-netlabel'd packets under MLS (problematic then to use unlabeled SID
> as the basis) or deny it?

My goal is to have the ability to specify, in SELinux policy on a per-domain 
basis, access controls for both NetLabel'd and non-NetLabel'd traffic.  Right 
now you can only specify access for NetLabel'd traffic using SELinux policy, 
restricting non-NetLabel'd traffic must be done outside of the SELinux policy 
on a system wide scale:

 # netlabelctl unlbl allow on|off

[I'm not ignoring you compatibility comments, I'm just trying to focus the 
discussion a bit until we resolve the core issue]

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Stephen Smalley]

On Tue, 2007-03-20 at 17:34 -0400, Paul Moore wrote:
> On Tuesday 20 March 2007 2:43:31 pm Stephen Smalley wrote:
> > On Tue, 2007-03-20 at 13:58 -0400, Paul Moore wrote:
> > > Yes, while it is both simple and tempting I don't see that solution as
> > > viable since it requires encoding meaning into the MLS sensitivity
> > > labels.  I understand that in certain other MLS implementations specific
> > > sensitivity labels have been given "special" meaning but I think doing so
> > > in an implementation as flexible as SELinux is a mistake.
> >
> > I wasn't actually suggesting any special or fixed meaning for a
> > particular label value in the code, just assigning the unlabeled SID a
> > level that dominates all of the levels that are legitimate for the
> > system in policy (which is actually what current policy does - unlabeled
> > sid is mapped to mls_systemhigh definition in refpolicy), and then using
> > the ordinary MLS logic to ensure that packets with such a level cannot
> > be received without network MLS overrides.  Then any non-MLS-privileged
> > application would be denied access to such "unlabeled" packets, vs. the
> > netlabel'd packets that would have a MLS value < systemhigh.
> 
> I think by creating a sensitivity label that dominates every other label on 
> the system, i.e. SystemHigh, and then restricting that label from being used 
> by the network does in fact grant some special meaning to that label.  
> Perhaps I'm using the wrong terminology but the point I am trying to make is 
> that I would prefer to see NetLabel have the ability to support every 
> sensitivity label on the system (granted some protocols may impose their own 
> restrictions but others do not).

Same issue arises for unlabeled filesystems or any other unlabeled
object, and that is why the unlabeled initial SID has the systemhigh
level - to prevent reading by untrusted processes since it may contain
data at any level.  Although in the unlabeled filesystem case, you can
use a context mount to map the entire filesystem to a given level.

> > So what is your goal?  Do you want to allow
> > non-netlabel'd packets under MLS (problematic then to use unlabeled SID
> > as the basis) or deny it?
> 
> My goal is to have the ability to specify, in SELinux policy on a per-domain 
> basis, access controls for both NetLabel'd and non-NetLabel'd traffic.  Right 
> now you can only specify access for NetLabel'd traffic using SELinux policy, 
> restricting non-NetLabel'd traffic must be done outside of the SELinux policy 
> on a system wide scale:
> 
>  # netlabelctl unlbl allow on|off

Always applying the permission check would allow such control, but the
the issue is that if you use the unlabeled initial SID for the
non-netlabel'd traffic, then the only way to allow a process to receive
the packets would be to give its domain MLS networking overrides, and at
that point, it could receive not only non-netlabel'd traffic but also
netlabel'd traffic with a higher level if you allow it to receive any
netlabel'd traffic at all.  Which limits you to one of (receive all
non-netlabel'd traffic, receive netlabel'd traffic that I dominate, or
receive all traffic even if it dominates my level) as your per-domain
options.  Is that sufficient?

It also seems that you might want the ability to distinguish among
different kinds of non-netlabel'd traffic based on receiving network
interface, so you could map some of that traffic to one level and some
of it to another level (which is actually closer in concept to the
netmsg sids, as they can be configured per netif in policy, although
nothing is using that support currently - legacy of when we were using
it as the default packet label for incoming traffic on a network
interface).

So an alternative would be to use the netmsg SID (or even the per-netif
netmsg SIDs obtained via sel_netif_sids(), specified in netifcon
statements in policy, should be supported by libsemanage/libsepol but
not in the current semanage interface) for the non-netlabel'd traffic
rather than the other way around.  Then you aren't forced to having
SystemHigh on that traffic, and can even support per-NIC levels in the
future.  Although that will yield the amusing situation that your
netlabel'd traffic will still have unlabeled_t and your non-netlabel'd
traffic will have some other type.

> [I'm not ignoring you compatibility comments, I'm just trying to focus the 
> discussion a bit until we resolve the core issue]

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

On Wednesday, March 21 2007 8:20:35 am Stephen Smalley wrote:
> On Tue, 2007-03-20 at 17:34 -0400, Paul Moore wrote:
> > On Tuesday 20 March 2007 2:43:31 pm Stephen Smalley wrote:
> > > So what is your goal?  Do you want to allow
> > > non-netlabel'd packets under MLS (problematic then to use unlabeled SID
> > > as the basis) or deny it?
> >
> > My goal is to have the ability to specify, in SELinux policy on a
> > per-domain basis, access controls for both NetLabel'd and non-NetLabel'd
> > traffic.  Right now you can only specify access for NetLabel'd traffic
> > using SELinux policy, restricting non-NetLabel'd traffic must be done
> > outside of the SELinux policy on a system wide scale:
> >
> >  # netlabelctl unlbl allow on|off
>
> Always applying the permission check would allow such control, but the
> the issue is that if you use the unlabeled initial SID for the
> non-netlabel'd traffic, then the only way to allow a process to receive
> the packets would be to give its domain MLS networking overrides, and at
> that point, it could receive not only non-netlabel'd traffic but also
> netlabel'd traffic with a higher level if you allow it to receive any
> netlabel'd traffic at all.  Which limits you to one of (receive all
> non-netlabel'd traffic, receive netlabel'd traffic that I dominate, or
> receive all traffic even if it dominates my level) as your per-domain
> options.  Is that sufficient?

I was also planning on modifying the MLS constraint in a similar fashion to 
how the IPsec association constraints from recvfrom/sendto so that the 
NetLabel recvfrom constraint would look something like this:

 mlsconstrain { tcp_socket udp_socket rawip_socket } recvfrom
         (( l1 eq l2 ) or
          (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
          ( t1 == mlsnetread ) or
          ( t2 == unlabeled_t ));

This should solve the problem on the default SystemHigh MLS sensitivity label 
assigned to the unlabeled initial SID while increasing the similarities 
between labeled IPsec and NetLabel (for better or worse).  Once again, this 
assumes that the netmsg initial SID would have a type other than unlabeled_t.

> It also seems that you might want the ability to distinguish among
> different kinds of non-netlabel'd traffic based on receiving network
> interface, so you could map some of that traffic to one level and some
> of it to another level (which is actually closer in concept to the
> netmsg sids, as they can be configured per netif in policy, although
> nothing is using that support currently - legacy of when we were using
> it as the default packet label for incoming traffic on a network
> interface).

This is an interesting idea, one which I have tossed around since I started 
the NetLabel work.  In fact, have the reason for making a separate 
unlabeled "module" in NetLabel was to help break out unlabeled packet 
handling to make life easier if we wanted to go this route.  I know several 
existing MLS systems can be configured to assign default MLS sensitivity 
labels to packets coming in on a specific interface, it only seems reasonable 
that we would support a similar capability.

However, I postponed doing any work on this when I thought 
SECMARK/secid-reconciliation might be able to solve some part of this; 
although we know now that it is not the case (at least in the getpeercon() 
sense).  My only concern now about doing something like this is how the 
SELinux community would respond to getpeercon() returning a context for a 
peer which is not actually sending labeled traffic.

> So an alternative would be to use the netmsg SID (or even the per-netif
> netmsg SIDs obtained via sel_netif_sids(), specified in netifcon
> statements in policy, should be supported by libsemanage/libsepol but
> not in the current semanage interface) for the non-netlabel'd traffic
> rather than the other way around.  Then you aren't forced to having
> SystemHigh on that traffic, and can even support per-NIC levels in the
> future.  Although that will yield the amusing situation that your
> netlabel'd traffic will still have unlabeled_t and your non-netlabel'd
> traffic will have some other type.

Heh, if we went that route I don't think I would ever be able to answer all of 
the emails asking why the unlabeled_t packets are the ones coming from the 
labeled network and the unlabeled network packets would have type foo ... ;)

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

It's spring here in the New England states with a projected high temperature 
of 91F degrees so it's time to do a little spring cleaning of my INBOX/Todo 
List ...

On Tuesday 20 March 2007 2:43:31 pm Stephen Smalley wrote:
> On Tue, 2007-03-20 at 13:58 -0400, Paul Moore wrote:
> > To get back to the compatibility question, current policy gives
> > unrestricted access to NetLabel (this may only be in RHEL5 right now but
> > Dan Walsh said he will be submitting the upstream [add Dan to the CC
> > line]):
> >
> >  allow domains unlabeled_t:{ tcp_socket udp_socket rawip_socket }
> > recvfrom;
> >
> > So in the worst case of a new policy on an old kernel, rebooted with a
> > newly defined SECINITSID_NETMSG value only domains which are only allowed
> > to receive NetLabel traffic will be blocked.  I consider this acceptable
> > as it is likely that anyone wishing to restrict domains only to labeled
> > traffic will want to upgrade to a kernel which supports this
> > functionality.
>
> IIUC, old/existing kernels skip the check altogether for non-netlabel'd
> traffic and apply the check with a context derived from base SID
> SECINITSID_UNLABELED (plus netlabel MLS value) for netlabel'd traffic,
> and old/existing policy allows the check for unlabeled_t (if the MLS
> constraint passes on the MLS value).

Yep, that's correct.

> New kernels would always apply the 
> check, using SECINITSID_UNLABELED for non-netlabel'd traffic and a
> context derived from base SID SECINITSID_NETMSG (plus netlabel MLS
> value) for netlabel'd traffic, allowing the check for netlabel_t (if the
> MLS constraint passes).

Yep.  The only clarification I have for the above statement is that incoming 
non-netlabel'd traffic, i.e. packets labeled 
SECINITSID_UNLABELED/unlabeled_t, would have a MLS constraint override 
similar to what is done for labeled IPsec.  This was already discussed 
earlier in the thread but after you made the comments below.

> What would new policy do for unlabeled_t with 
> SystemHigh?  I'd expect the check to fail in that case even if you allow
> it in the TE policy due to the MLS constraints except for processes with
> MLS overrides.

See the above comment regarding MLS constraints on unlabeled_t; this should 
not be an issue.

> So as I see it, the situation would be:
> 1) old kernel / new policy - still no checking of non-netlabel'd
> traffic, and checks for netlabel'd traffic will still be based on
> SECINITSID_UNLABELED, so it depends on what is allowed for unlabeled_t
> in new policy - possibly no breakage here,

In this situation the only problem I see is a MLS user making use of NetLabel. 
Labeled traffic will be labeled with unlabeled_t which according to the new 
policy has a MLS override associated with it which could result in previously 
denied traffic now being allowed.  This happens regardless of if the kernerl 
is rebooted or not after installing the new policy as the old kernel will 
always use SECINITSID_UNLABELED for the NetLabel "base SID".

I can't think of a good solution to this case other than to have the user 
upgrade the kernel along with the policy.  The only saving grace here is that 
this only affects users who care about both MLS and NetLabel - so none of you 
TE guys should care ;)

> 2) new kernel / old policy - checks for non-netlabel'd traffic will be
> against SECINITSID_UNLABELED (TE allowed, MLS denied except for
> processes with MLS overrides), checks for netlabel'd traffic will be
> against SECINITSID_NETMSG but will end up mapping to the unlabeled
> context still in the old policy, so likely TE allowed and MLS will
> depend on the particular value in the packet.  Here I expect breakage
> from the denials on non-netlabel'd traffic.

Here both SECINITSID_UNLABELED and SECINITSID_NETMSG are going to map to 
unlabeled_t and the kernel will perform a check against the receiving domain 
and unlabeled_t for both the labeled and unlabeled case as a result.  As you 
stated above, in the unlabeled traffic case this should most likely be fine 
from a TE point of view but could cause problems with people running MLS 
policies depending on the MLS label of the receiving domain.  In the case of 
labeled traffic there really shouldn't be any noticeable change from the 
old/current behavior.

> 3) new kernel / old policy -> new policy on reload - if the new policy
> drops access to unlabeled_t, then in this scenario we will end up
> denying access on all traffic since the initial SIDs won't be remapped
> until reboot.

Yes, but I think by default we would allow unlabeled traffic much like we do 
now for labeled IPsec.  The only real problem would be third-party policy 
modules which haven't been updated.  In this case I think dropping all 
traffic would be the "safe" thing to do.

The next logical questions are first, does anyone have a good idea on how to 
solve these compatibility breaks?  Second, assuming there is not an easy fix, 
do people consider the issues above to be deal breakers?

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Stephen Smalley]

On Mon, 2007-04-23 at 14:56 -0400, Paul Moore wrote:
> It's spring here in the New England states with a projected high temperature 
> of 91F degrees so it's time to do a little spring cleaning of my INBOX/Todo 
> List ...
> 
> On Tuesday 20 March 2007 2:43:31 pm Stephen Smalley wrote:
> > On Tue, 2007-03-20 at 13:58 -0400, Paul Moore wrote:
> > > To get back to the compatibility question, current policy gives
> > > unrestricted access to NetLabel (this may only be in RHEL5 right now but
> > > Dan Walsh said he will be submitting the upstream [add Dan to the CC
> > > line]):
> > >
> > >  allow domains unlabeled_t:{ tcp_socket udp_socket rawip_socket }
> > > recvfrom;
> > >
> > > So in the worst case of a new policy on an old kernel, rebooted with a
> > > newly defined SECINITSID_NETMSG value only domains which are only allowed
> > > to receive NetLabel traffic will be blocked.  I consider this acceptable
> > > as it is likely that anyone wishing to restrict domains only to labeled
> > > traffic will want to upgrade to a kernel which supports this
> > > functionality.
> >
> > IIUC, old/existing kernels skip the check altogether for non-netlabel'd
> > traffic and apply the check with a context derived from base SID
> > SECINITSID_UNLABELED (plus netlabel MLS value) for netlabel'd traffic,
> > and old/existing policy allows the check for unlabeled_t (if the MLS
> > constraint passes on the MLS value).
> 
> Yep, that's correct.
> 
> > New kernels would always apply the 
> > check, using SECINITSID_UNLABELED for non-netlabel'd traffic and a
> > context derived from base SID SECINITSID_NETMSG (plus netlabel MLS
> > value) for netlabel'd traffic, allowing the check for netlabel_t (if the
> > MLS constraint passes).
> 
> Yep.  The only clarification I have for the above statement is that incoming 
> non-netlabel'd traffic, i.e. packets labeled 
> SECINITSID_UNLABELED/unlabeled_t, would have a MLS constraint override 
> similar to what is done for labeled IPsec.  This was already discussed 
> earlier in the thread but after you made the comments below.
> 
> > What would new policy do for unlabeled_t with 
> > SystemHigh?  I'd expect the check to fail in that case even if you allow
> > it in the TE policy due to the MLS constraints except for processes with
> > MLS overrides.
> 
> See the above comment regarding MLS constraints on unlabeled_t; this should 
> not be an issue.
> 
> > So as I see it, the situation would be:
> > 1) old kernel / new policy - still no checking of non-netlabel'd
> > traffic, and checks for netlabel'd traffic will still be based on
> > SECINITSID_UNLABELED, so it depends on what is allowed for unlabeled_t
> > in new policy - possibly no breakage here,
> 
> In this situation the only problem I see is a MLS user making use of NetLabel. 
> Labeled traffic will be labeled with unlabeled_t which according to the new 
> policy has a MLS override associated with it which could result in previously 
> denied traffic now being allowed.  This happens regardless of if the kernerl 
> is rebooted or not after installing the new policy as the old kernel will 
> always use SECINITSID_UNLABELED for the NetLabel "base SID".
> 
> I can't think of a good solution to this case other than to have the user 
> upgrade the kernel along with the policy.  The only saving grace here is that 
> this only affects users who care about both MLS and NetLabel - so none of you 
> TE guys should care ;)
> 
> > 2) new kernel / old policy - checks for non-netlabel'd traffic will be
> > against SECINITSID_UNLABELED (TE allowed, MLS denied except for
> > processes with MLS overrides), checks for netlabel'd traffic will be
> > against SECINITSID_NETMSG but will end up mapping to the unlabeled
> > context still in the old policy, so likely TE allowed and MLS will
> > depend on the particular value in the packet.  Here I expect breakage
> > from the denials on non-netlabel'd traffic.
> 
> Here both SECINITSID_UNLABELED and SECINITSID_NETMSG are going to map to 
> unlabeled_t and the kernel will perform a check against the receiving domain 
> and unlabeled_t for both the labeled and unlabeled case as a result.  As you 
> stated above, in the unlabeled traffic case this should most likely be fine 
> from a TE point of view but could cause problems with people running MLS 
> policies depending on the MLS label of the receiving domain.  In the case of 
> labeled traffic there really shouldn't be any noticeable change from the 
> old/current behavior.
> 
> > 3) new kernel / old policy -> new policy on reload - if the new policy
> > drops access to unlabeled_t, then in this scenario we will end up
> > denying access on all traffic since the initial SIDs won't be remapped
> > until reboot.
> 
> Yes, but I think by default we would allow unlabeled traffic much like we do 
> now for labeled IPsec.  The only real problem would be third-party policy 
> modules which haven't been updated.  In this case I think dropping all 
> traffic would be the "safe" thing to do.
> 
> The next logical questions are first, does anyone have a good idea on how to 
> solve these compatibility breaks?  Second, assuming there is not an easy fix, 
> do people consider the issues above to be deal breakers?

It sounds as though it has a very limited scope (MLS & NetLabel), and
the kernel/policy mismatch is less likely in that environment (as
changing the kernel or the policy would require re-evaluation, and in
particular, the policy change modifies the MLS constraints).  So
possibly just a matter of documenting the dependency between the kernel
version and the policy version for MLS.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

On Monday 23 April 2007 4:36:58 pm Stephen Smalley wrote:
> On Mon, 2007-04-23 at 14:56 -0400, Paul Moore wrote:
> > The next logical questions are first, does anyone have a good idea on how
> > to solve these compatibility breaks?  Second, assuming there is not an
> > easy fix, do people consider the issues above to be deal breakers?
>
> It sounds as though it has a very limited scope (MLS & NetLabel), and
> the kernel/policy mismatch is less likely in that environment (as
> changing the kernel or the policy would require re-evaluation, and in
> particular, the policy change modifies the MLS constraints).  So
> possibly just a matter of documenting the dependency between the kernel
> version and the policy version for MLS.

Okay, that sounds good to me.

Thanks.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.