SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

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;

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

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;

Quoted 6 lines · Paul Moore

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?

Quoted 9 lines

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

Quoted 2 lines

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.

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

Quoted 5 lines · Paul Moore

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.

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?

Quoted 7 lines · Stephen Smalley

Quoted 5 lines · Paul Moore

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.

Quoted 9 lines

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

Quoted 3 lines

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]

Quoted 5 lines · Paul Moore

Quoted 3 lines · Stephen Smalley

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?

Quoted 7 lines

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.

Quoted 8 lines · Paul Moore

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;

Quoted 6 lines

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.

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

Quoted 16 lines · Stephen Smalley

Quoted 8 lines · Paul Moore

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;

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 7 lines

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.

Quoted 4 lines

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?

Quoted 3 lines · Paul Moore

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.