Static/fallback external labels for NetLabel

label:system_u:system_r:unconfined_t:s0

This patchset adds the static/fallback labeling feature to NetLabel that has been requested on the SELinux mailing list more and more recently. This new bit of functionality also matches what can be found on similar trusted/labeled OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready for "upstreaming" so please do not pull this into any tree bound for the mainline kernel; I still need to do more review and testing of the code. However, I know there are several of you on this list that have been anxiously awaiting this patchset so I thought I would make an early release so you could get a peek and test it out. I won't be able to work on this patchset much, if at all, between August 10th and the 20th so don't expect an update from me until the end of August.

The basic idea is that currently there is no method for providing an external label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO or labeled IPsec is not in use. This patch adds a mechanism for providing a static fallback label, specified per interface/network, which is used when a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

For those of you wishing to try this patchset, it is backed against Linus' linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll have many problems applying the patchset to later trees at this point in the 2.6.23 release cycle. In addition to the kernel patches you will also need a modified version of netlabelctl from the netlabel_tools package. A very crude version of the modified tools can be found in the netlabel_tools SVN repository in the static_label branch. Please check the NetLabel website on SourceForge,
http://netlabel.sf.net, for information on the SVN repository. The three new netlabelctl commands are as follows:

 # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
 # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
 # netlabelctl -p unlbl list

DEV = interface, examples: eth0, lo
ADDR = IP address, examples: 192.168.0.3, ::1
MASK = IP address mask length, examples 8, 24, 64
LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2

For example, if you wanted to label all inbound traffic on eth1 from 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would type:

 # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
                         label:system_u:object_r:staticlabel_t:s7

Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted from the command the address is assumed to be a host address, not a network, and the maximum mask size for that address family is used. If you do not wish to specify an address, simply use a address mask of zero, "/0", which will cause all addresses within that address family to match.

Thanks so much! I was looking forward to your patch set.

I tried to build kernel with the patch and configure a fallbacked label, but the netlabelctl returns the following error message:

[root@masu ~]# netlabelctl unlbl add interface:eth0 address:192.168.11.0/24
label:system_u:system_r:unconfined_t:s0
netlabelctl: error, invalid argument or parameter

The kernel config contains CONFIG_NETLABEL=y, and the netlabelctl command is built from the latest svn repository.
Are any more configurations necessary?

This patchset adds the static/fallback labeling feature to NetLabel that has been requested on the SELinux mailing list more and more recently. This new bit of functionality also matches what can be found on similar trusted/labeled OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready for "upstreaming" so please do not pull this into any tree bound for the mainline kernel; I still need to do more review and testing of the code. However, I know there are several of you on this list that have been anxiously awaiting this patchset so I thought I would make an early release so you could get a peek and test it out. I won't be able to work on this patchset much, if at all, between August 10th and the 20th so don't expect an update from me until the end of August.

The basic idea is that currently there is no method for providing an external label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO or labeled IPsec is not in use. This patch adds a mechanism for providing a static fallback label, specified per interface/network, which is used when a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

For those of you wishing to try this patchset, it is backed against Linus' linux-2.6 git tree from the afternoon of August 6th, but I don't imagine you'll have many problems applying the patchset to later trees at this point in the 2.6.23 release cycle. In addition to the kernel patches you will also need a modified version of netlabelctl from the netlabel_tools package. A very crude version of the modified tools can be found in the netlabel_tools SVN repository in the static_label branch. Please check the NetLabel website on SourceForge,
http://netlabel.sf.net, for information on the SVN repository. The three new netlabelctl commands are as follows:

 # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>] label:<LABEL>
 # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
 # netlabelctl -p unlbl list

DEV = interface, examples: eth0, lo
ADDR = IP address, examples: 192.168.0.3, ::1
MASK = IP address mask length, examples 8, 24, 64
LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2

For example, if you wanted to label all inbound traffic on eth1 from 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you would type:

 # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
                         label:system_u:object_r:staticlabel_t:s7

Both IPv4 and IPv6 addresses can be used and if the address mask is ommitted from the command the address is assumed to be a host address, not a network, and the maximum mask size for that address family is used. If you do not wish to specify an address, simply use a address mask of zero, "/0", which will cause all addresses within that address family to match.

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric.

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

Quoted 2 lines · Stephen Smalley

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric.

NetLabel has always been designed as a framework to support multiple different types of labeling protocols/mechanisms. Adding this bit of functionality to NetLabel isn't a major departure from the existing architecture. The only real substantial changes to the underlying NetLabel framework are the passing of the IP address family to some of the NetLabel APIs (minor tweak) and the addition of a secid field to the NetLabel security attributes struct (also a pretty minor tweak).

I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem, further explanation might help ...

I understand your concern regarding the additional configuration. While netlabelctl and netlabel_tools are not new, they may be new to users who want to make use of this new feature. On an older thread Josh and I had a bit of a discussion regarding this and while we never really arrived at a magic solution we did talk about integrating some, or all, of the netlabelctl functionality into semanage. This wouldn't be that difficult as most of the "intelligence" in netlabelctl is already in a separate library; adding that library to semanage should not be that difficult. Would that help ease your configuration concerns?

Quoted 17 lines

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

Quoted 2 lines

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

I still think merging the two types of packet labels, "internal" and "external" is a mistake; I stated my reasoning a few times before so I will save people following this thread from reading it again.

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types of packet labels is not helpful I wonder if the following would a worthwhile effort:

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back compat_net or not is not important.

* Convert the external labeling protocols to make use of the SECMARK secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

As you stated above, there are some obvious advantages here including "free" loopback labeling, easier implementation of general iptables forwarding controls in the future, as well as some general implementation cleanups in the existing code. If we did decide to go this route, I think I would prefer to keep a fallback/static labeling mechanism similar to what is being done in this patchset, with the obvious change being made to utilize the new SECMARK secid value. We've seen all of the issues that come to light when we start to make use of iptables to set labels on packets and not all of them have elegant solutions; one could even argue this is one of the reasons SECMARK as an internal label has failed to achieve much use.

Quoted 4 lines · Paul Moore

On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem, further explanation might help ...

We want a fallback mechanism that is agnostic to the labeled networking mechanism. netlabel may be a "framework" but only for a particular subset of such mechanisms, i.e. explicit packet labeling. Putting functionality into it that should also apply to xfrm labeling is wrong.

Quoted 9 lines

I understand your concern regarding the additional configuration. While netlabelctl and netlabel_tools are not new, they may be new to users who want to make use of this new feature. On an older thread Josh and I had a bit of a discussion regarding this and while we never really arrived at a magic solution we did talk about integrating some, or all, of the netlabelctl functionality into semanage. This wouldn't be that difficult as most of the "intelligence" in netlabelctl is already in a separate library; adding that library to semanage should not be that difficult. Would that help ease your configuration concerns?

I don't care what we call the userland tool; it is still using netlabel-specific interfaces and infrastructure.

And re-inventing the secmark wheel.

Quoted 20 lines

Quoted 19 lines

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

Quoted 3 lines

I still think merging the two types of packet labels, "internal" and "external" is a mistake; I stated my reasoning a few times before so I will save people following this thread from reading it again.

No one is using the "internal" labels AFAIK, and conceptually, I don't see a security goal that you would enforce that way that isn't more cleanly expressed (and more useful) in terms of "external" label.

Quoted 10 lines

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types of packet labels is not helpful I wonder if the following would a worthwhile effort:

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back
compat_net or not is not important.

Agree with the first part, but not the second. The secmark packet checks are actually what we want, with some modification. IOW, we want a unified set of checks independent of labeled networking mechanism so that we can have coherent policy.

And while we do away with any
separate notion of "internal" vs "external", we'd still use iptables secmark rules to define and apply the fallback labels - that is more expressive and generic than your approach.

Quoted 4 lines

* Convert the external labeling protocols to make use of the SECMARK
secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

I'm not so sure it is so marginal for netlabel - being able to use a field from the skb (once initially set for the packet) instead of inspecting the payload should be a win.

From a functionality standpoint it is marginal for explicitly labeled packets

Quoted 11 lines

As you stated above, there are some obvious advantages here including "free" loopback labeling, easier implementation of general iptables forwarding controls in the future, as well as some general implementation cleanups in the existing code. If we did decide to go this route, I think I would prefer to keep a fallback/static labeling mechanism similar to what is being done in this patchset, with the obvious change being made to utilize the new SECMARK secid value. We've seen all of the issues that come to light when we start to make use of iptables to set labels on packets and not all of them have elegant solutions; one could even argue this is one of the reasons SECMARK as an internal label has failed to achieve much use.

You'll have to elaborate on that one; defining an iptables rule to apply a fallback label seems much more general and expressive than the netlabelctl approach.

See my comments above about the difference in getpeercon() behavior. There are also implementation issues regarding the use of iptables, the "flush all" case being a good example.

Quoted 10 lines · Stephen Smalley

Quoted 4 lines · Paul Moore

On Thursday 09 August 2007 8:42:43 am Stephen Smalley wrote:
I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem, further explanation might help ...

We want a fallback mechanism that is agnostic to the labeled networking mechanism. netlabel may be a "framework" but only for a particular subset of such mechanisms, i.e. explicit packet labeling. Putting functionality into it that should also apply to xfrm labeling is wrong.

I guess this is always going to be a bit of a religious argument then, as I tend to think of this feature as a static external label and implementing this feature as part of an existing external labeling system/framework makes the most sense to me. Regardless, it's probably best to focus on the other issues in this thread, namely what to do with SECMARK, first as that will have a huge impact on this topic.

Quoted 12 lines

Quoted 9 lines

I understand your concern regarding the additional configuration. While netlabelctl and netlabel_tools are not new, they may be new to users who want to make use of this new feature. On an older thread Josh and I had a bit of a discussion regarding this and while we never really arrived at a magic solution we did talk about integrating some, or all, of the netlabelctl functionality into semanage. This wouldn't be that difficult as most of the "intelligence" in netlabelctl is already in a separate library; adding that library to semanage should not be that difficult. Would that help ease your configuration concerns?

I don't care what we call the userland tool; it is still using netlabel-specific interfaces and infrastructure.

Quoted 1 line

And re-inventing the secmark wheel.

Well, only if you redefine SECMARK to a greater scope that what it is used for today. Granted, both this new static/fallback label feature use IP header information to derive a packet label but that's about the only similarity I see here. If we do decide to redefine SECMARK then you'll be correct, no need for this patchset.

Quoted 24 lines

Quoted 23 lines

Quoted 17 lines

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

Quoted 2 lines

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

I still think merging the two types of packet labels, "internal" and "external" is a mistake; I stated my reasoning a few times before so I will save people following this thread from reading it again.

Quoted 3 lines

No one is using the "internal" labels AFAIK, and conceptually, I don't see a security goal that you would enforce that way that isn't more cleanly expressed (and more useful) in terms of "external" label.

Okay, so let's get rid of the "internal" label.

Quoted 11 lines

Quoted 10 lines

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types of packet labels is not helpful I wonder if the following would a worthwhile effort:

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back
compat_net or not is not important.

Quoted 4 lines

Agree with the first part, but not the second. The secmark packet checks are actually what we want, with some modification. IOW, we want a unified set of checks independent of labeled networking mechanism so that we can have coherent policy.

Looking again at what I typed, I realized I worded it very poorly. What I mean was that we should remove the iptables/SECMARK hooks so that the iptables bits no longer set the label of a packet, i.e. remove the internal labeling as we know it today.

Quoted 4 lines

And while we do away with any
separate notion of "internal" vs "external", we'd still use iptables secmark rules to define and apply the fallback labels - that is more expressive and generic than your approach.

My main concern with this goes back to the failed secid-reconciliation efforts; the key problem here has to do with the behavior of getpeercon(). As it stands right now, in the case of of a UNIX domain socket we return the label of the domain on the other end, the same with network sockets. The current proposed static/fallback mechanism is intentionally coarse grained with the granularity limit being a single IP address/host. My reasoning being that if the other host is not able or willing to send labeled traffic we should treat it as a single label host. This seems to mesh well with what has been done in the past.

If we adopt the revised SECMARK/iptables method then this is no guaranteed to be the case. With the added flexibility/granularity of iptables we could arrive in a situation where a single IP address/host could take on multiple different labels based on the type of connection. Maybe this is what you want, but it is a departure from what we do today as well as what I've heard has been done in the past. Then again, just because we've always done it this way doesn't mean it's the best solution.

Quoted 5 lines

Quoted 4 lines

* Convert the external labeling protocols to make use of the SECMARK
secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

Quoted 5 lines

I'm not so sure it is so marginal for netlabel - being able to use a field from the skb (once initially set for the packet) instead of inspecting the payload should be a win.

From a functionality standpoint it is marginal for explicitly labeled packets

because you already have the label as part of the packet's header/payload; that is what I was referring to. I agree there are some obvious performance advantages if you have to look at the label twice.

Quoted 12 lines

Quoted 11 lines

As you stated above, there are some obvious advantages here including "free" loopback labeling, easier implementation of general iptables forwarding controls in the future, as well as some general implementation cleanups in the existing code. If we did decide to go this route, I think I would prefer to keep a fallback/static labeling mechanism similar to what is being done in this patchset, with the obvious change being made to utilize the new SECMARK secid value. We've seen all of the issues that come to light when we start to make use of iptables to set labels on packets and not all of them have elegant solutions; one could even argue this is one of the reasons SECMARK as an internal label has failed to achieve much use.

Quoted 3 lines

You'll have to elaborate on that one; defining an iptables rule to apply a fallback label seems much more general and expressive than the netlabelctl approach.

See my comments above about the difference in getpeercon() behavior. There are also implementation issues regarding the use of iptables, the "flush all" case being a good example. Yes, there have been solutions tossed around but nothing concrete. There is also the ongoing debate about how to properly generate iptables rules in policy, without a good solution here anything we do that uses iptables to label packets is going to have a hard time getting adopted by users.

Quoted 10 lines · Paul Moore

Quoted 1 line · Stephen Smalley

On Thu, 2007-08-09 at 09:29 -0400, Paul Moore wrote:

If we adopt the revised SECMARK/iptables method then this is no guaranteed to be the case. With the added flexibility/granularity of iptables we could arrive in a situation where a single IP address/host could take on multiple different labels based on the type of connection. Maybe this is what you want, but it is a departure from what we do today as well as what I've heard has been done in the past. Then again, just because we've always done it this way doesn't mean it's the best solution.

My preference would be to have it assigned a single default/fallback label based on iptables, and then overridden after a permission check if labeled networking is in use. No other mutations.

Quoted 12 lines

Quoted 11 lines

Quoted 4 lines

* Convert the external labeling protocols to make use of the SECMARK
secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

I'm not so sure it is so marginal for netlabel - being able to use a field from the skb (once initially set for the packet) instead of inspecting the payload should be a win.

From a functionality standpoint it is marginal for explicitly labeled packets

Quoted 3 lines

because you already have the label as part of the packet's header/payload; that is what I was referring to. I agree there are some obvious performance advantages if you have to look at the label twice.

Propagation/preservation of the label throughout also gets simpler and more reliable, and possibly goes beyond what you can do today.

How do you deal with ICMP replies currently?

Quoted 16 lines

Quoted 12 lines

Quoted 11 lines

As you stated above, there are some obvious advantages here including "free" loopback labeling, easier implementation of general iptables forwarding controls in the future, as well as some general implementation cleanups in the existing code. If we did decide to go this route, I think I would prefer to keep a fallback/static labeling mechanism similar to what is being done in this patchset, with the obvious change being made to utilize the new SECMARK secid value. We've seen all of the issues that come to light when we start to make use of iptables to set labels on packets and not all of them have elegant solutions; one could even argue this is one of the reasons SECMARK as an internal label has failed to achieve much use.

Quoted 3 lines

You'll have to elaborate on that one; defining an iptables rule to apply a fallback label seems much more general and expressive than the netlabelctl approach.

Quoted 7 lines

See my comments above about the difference in getpeercon() behavior. There are also implementation issues regarding the use of iptables, the "flush all" case being a good example. Yes, there have been solutions tossed around but nothing concrete. There is also the ongoing debate about how to properly generate iptables rules in policy, without a good solution here anything we do that uses iptables to label packets is going to have a hard time getting adopted by users.

We don't generate netlabelctl configuration or ipsec configuration from policy, so this isn't really different. Ultimately, you'd have some front-end tool that lets you configure labeled networking, including selection of mechanism (NetLabel/CIPSO or NetLabel/other or labeled IPSEC), selection of appropriate settings for that mechanism, and fallbacks (via secmark).

Separate table would likely be useful.

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types of packet labels is not helpful I wonder if the following would a worthwhile effort:

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back compat_net or not is not important.

* Convert the external labeling protocols to make use of the SECMARK secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

Quoted 4 lines · Paul Moore

* Convert the external labeling protocols to make use of the SECMARK
secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

The way we were discussing this (off-list) was that we'd allow iptables secmark labeling to set fallback/default labels, which may be overridden by external labeling (Netlabel, IPsec).

Quoted 6 lines · James Morris

Quoted 4 lines · Paul Moore

* Convert the external labeling protocols to make use of the SECMARK
secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

Quoted 3 lines

The way we were discussing this (off-list) was that we'd allow iptables secmark labeling to set fallback/default labels, which may be overridden by external labeling (Netlabel, IPsec).

If I understand you correctly, SECMARK would continue as SECMARK as we know it today, the only real difference is that if getpeercon() would return failure because NetLabel or labeled IPsec was not in use we would return the SECMARK label?

Quoted 2 lines · Stephen Smalley

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric.

NetLabel has always been designed as a framework to support multiple

types of labeling protocols/mechanisms. Adding this bit of functionality

NetLabel isn't a major departure from the existing architecture. The only

real substantial changes to the underlying NetLabel framework are the

of the IP address family to some of the NetLabel APIs (minor tweak) and

addition of a secid field to the NetLabel security attributes struct (also

pretty minor tweak).

I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem,

explanation might help ...

... I also think that there must be consistency forced between the different peer labeling mechanisms. If I get packets that are specified as top_secret via CIPSO over an ipsec association labeled as user_u:user_r:user_t:secret, that packet should die.

Quoted 1 line · Darrel Goeddel

... I also think that there must be consistency forced between the

Quoted 1 line

peer labeling mechanisms. If I get packets that are specified as

Quoted 1 line

via CIPSO over an ipsec association labeled as

Quoted 1 line

that packet should die.

Yes. This is one of the places in the labeled networking code that has

bothered me. The current mashup of labels was rather a poor attempt at compromise by everyone involved and I think everyone will agree that we

to come up with a better solution.

Quoted 2 lines · Stephen Smalley

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric.

NetLabel has always been designed as a framework to support multiple different
types of labeling protocols/mechanisms. Adding this bit of functionality to NetLabel isn't a major departure from the existing architecture. The only real substantial changes to the underlying NetLabel framework are the passing

of the IP address family to some of the NetLabel APIs (minor tweak) and the addition of a secid field to the NetLabel security attributes struct (also a pretty minor tweak).

I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem, further explanation might help ...

I understand your concern regarding the additional configuration. While netlabelctl and netlabel_tools are not new, they may be new to users who want

to make use of this new feature. On an older thread Josh and I had a bit of a discussion regarding this and while we never really arrived at a magic solution we did talk about integrating some, or all, of the netlabelctl functionality into semanage. This wouldn't be that difficult as most of the "intelligence" in netlabelctl is already in a separate library; adding that library to semanage should not be that difficult. Would that help ease your configuration concerns?

Quoted 17 lines

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

Quoted 2 lines

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

I still think merging the two types of packet labels, "internal" and "external" is a mistake; I stated my reasoning a few times before so I will save people following this thread from reading it again.

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types

of packet labels is not helpful I wonder if the following would a worthwhile effort:

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back compat_net or not is not important.
* Convert the external labeling protocols to make use of the SECMARK secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

As you stated above, there are some obvious advantages here including "free" loopback labeling, easier implementation of general iptables forwarding controls in the future, as well as some general implementation cleanups in the existing code. If we did decide to go this route, I think I would prefer

to keep a fallback/static labeling mechanism similar to what is being done in

this patchset, with the obvious change being made to utilize the new SECMARK secid value. We've seen all of the issues that come to light when we start to make use of iptables to set labels on packets and not all of them have elegant solutions; one could even argue this is one of the reasons SECMARK as

an internal label has failed to achieve much use.

Signature · 7 lines

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Quoted 60 lines · --- Paul Moore

Quoted 2 lines · Stephen Smalley

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric.

NetLabel has always been designed as a framework to support multiple different
types of labeling protocols/mechanisms. Adding this bit of functionality to NetLabel isn't a major departure from the existing architecture. The only real substantial changes to the underlying NetLabel framework are the passing

of the IP address family to some of the NetLabel APIs (minor tweak) and the addition of a secid field to the NetLabel security attributes struct (also a pretty minor tweak).

I'm also a little confused about your concern over this new feature being NetLabel-centric? I guess I don't understand how that is a problem, further explanation might help ...

I understand your concern regarding the additional configuration. While netlabelctl and netlabel_tools are not new, they may be new to users who want

to make use of this new feature. On an older thread Josh and I had a bit of a discussion regarding this and while we never really arrived at a magic solution we did talk about integrating some, or all, of the netlabelctl functionality into semanage. This wouldn't be that difficult as most of the "intelligence" in netlabelctl is already in a separate library; adding that library to semanage should not be that difficult. Would that help ease your configuration concerns?

Quoted 17 lines

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

Quoted 2 lines

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

I still think merging the two types of packet labels, "internal" and "external" is a mistake; I stated my reasoning a few times before so I will save people following this thread from reading it again.

However, I agree that packet labeling is in a "weird" state right now and there is a lot of room for improvement. Bearing in mind your comments that SECMARK is effectively unused due to lack of demand and that having two types

of packet labels is not helpful I wonder if the following would a worthwhile effort:

Quoted 8 lines

* Do away with internal label concept completely, but leave the SECMARK secid field in the sk_buff struct. This includes removing the SECMARK related MAC checks on incoming traffic, whether we bring back compat_net or not is not important.
* Convert the external labeling protocols to make use of the SECMARK secid field in the sk_buff struct. The advantage to NetLabel and explicit labeling protocols is really marginal but this should be a huge win for labeled IPsec.

If y'all are going to look at this, please consider that secid's are SELinux specific and using them in system interfaces is an impediment to the development of other schemes. One important reason that Smack is using netlabel in favor of secmark is that secid interface.

Quoted 4 lines

If y'all are going to look at this, please consider that secid's are SELinux specific and using them in system interfaces is an impediment to the development of other schemes. One important reason that Smack is using netlabel in favor of secmark is that secid interface.

The secid notion is the only reason we have a field in the sk_buff at all. The original security blob in the sk_buff was rejected by David Miller when the LSM networking hooks were put forward by James; it comes back to lifecycle management and overhead. The secmark (just another name for a secid) construct in contrast avoids the lifecycle management requirement and due to its small fixed size avoids significant bloat. There is considerable doubt that we could even get it expanded to being a u64, much less turned into a security blob.

Quoted 1 line · Paul Moore

This patchset adds the static/fallback labeling feature to NetLabel that

Quoted 1 line

been requested on the SELinux mailing list more and more recently. This

Quoted 1 line

bit of functionality also matches what can be found on similar

Quoted 1 line

OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet

Quoted 3 lines

for "upstreaming" so please do not pull this into any tree bound for the mainline kernel; I still need to do more review and testing of the code. However, I know there are several of you on this list that have been

Quoted 1 line

awaiting this patchset so I thought I would make an early release so you

Quoted 1 line

get a peek and test it out. I won't be able to work on this patchset

Quoted 1 line

at all, between August 10th and the 20th so don't expect an update from

Quoted 3 lines

until the end of August.

The basic idea is that currently there is no method for providing an

Quoted 1 line

label to fallback on if a labeled networking mechanism such as

Quoted 1 line

or labeled IPsec is not in use. This patch adds a mechanism for

Quoted 1 line

static fallback label, specified per interface/network, which is used

Quoted 1 line

a NetLabel recognized labeling protocol (at this point CIPSO) is not in

Quoted 2 lines

For those of you wishing to try this patchset, it is backed against

Quoted 1 line

linux-2.6 git tree from the afternoon of August 6th, but I don't imagine

Quoted 1 line

have many problems applying the patchset to later trees at this point in

Quoted 1 line

2.6.23 release cycle. In addition to the kernel patches you will also

Quoted 1 line

modified version of netlabelctl from the netlabel_tools package. A very

Quoted 1 line

version of the modified tools can be found in the netlabel_tools SVN

Quoted 1 line

in the static_label branch. Please check the NetLabel website on

Quoted 1 line

http://netlabel.sf.net, for information on the SVN repository. The three

Quoted 3 lines

netlabelctl commands are as follows:

 # netlabelctl unlbl add interface:<DEV> address:<ADDR>[/<MASK>]

Quoted 10 lines

 # netlabelctl unlbl del interface:<DEV> address:<ADDR>[/<MASK>]
 # netlabelctl -p unlbl list

DEV = interface, examples: eth0, lo
ADDR = IP address, examples: 192.168.0.3, ::1
MASK = IP address mask length, examples 8, 24, 64
LABEL = LSM/SELinux label, example: system_u:object_r:unlabeled_t:s2

For example, if you wanted to label all inbound traffic on eth1 from 192.168.0.0/16 with the label "system_u:object_r:staticlabel_t:s7" you

Quoted 6 lines

type:

 # netlabelctl unlbl add interface:eth1 address:192.168.0.0/16 \
                         label:system_u:object_r:staticlabel_t:s7

Both IPv4 and IPv6 addresses can be used and if the address mask is

Quoted 1 line

from the command the address is assumed to be a host address, not a

Quoted 1 line

and the maximum mask size for that address family is used. If you do not

Quoted 1 line

to specify an address, simply use a address mask of zero, "/0", which

Quoted 1 line

cause all addresses within that address family to match.

Hi,

I like the functionality, but I don't like having yet another mechanism and configuration, and I'm concerned about it being netlabel-centric. Especially when we already have a more generic and flexible mechanism for specifying packet labels, i.e. secmark.

The only reason to not use secmark today for a fallback mechanism is the current separation between 'internal' and 'external' labels. But I don't believe that separation is necessary or useful, and secmark today is effectively unused. The original usage scenario for it simply hasn't materialized.

Meanwhile, getting secmark employed, not only as a mechanism for assigning default labels (via iptables rules) but also as a seamless way of propagating labels with socket buffers would solve a lot of our current limitations. We'd get loopback labeling for free, flexible and generic fallback labeling, forwarding controls would become straightforward, and PEERSEC/SCM_SECURITY becomes much simpler. NetLabel would benefit from it as well. There are alternative implementation approaches, but none as clean and efficient and reliable. There was a reason we put a sid in the sk_buff in the original SELinux implementations (prior to Linux 2.6 merge).

I've had some initial discussions with James, and he seemed open to revisiting this notion, so I think we need to take another look.

Because of the position I am in (needing to find something workable for actual
users), I have been trying to get my head aounrd the state of SELinux networking,
the ideas that have been talked about in the past, and how we can prevent the
SELinux networking infrastructure from resembling a Rube-Goldberg machine. I'll
be presenting some of the problems I perceive along with some very high level
ideas early next week.

Quoted 7 lines · Darrel Goeddel

Because of the position I am in (needing to find something workable for actual
users), I have been trying to get my head aounrd the state of SELinux networking,
the ideas that have been talked about in the past, and how we can prevent the
SELinux networking infrastructure from resembling a Rube-Goldberg

Quoted 4 lines

I'll
be presenting some of the problems I perceive along with some very high level
ideas early next week.

I think the problem we have faced in this area here is not enough focus on

general usability, and how to make this stuff useful beyond "lspp" customers. It is essential for SELinux to succeed that it is generally useful, and capable of addressing general security requirements, otherwise

we _effectively_ end up with a Trusted Solaris style fork, where you have this odd code in the corner that most people don't and won't use.

The proposal outlined in my last email is:

- Retain existing secmark facilities, allowing them to be used as a way to

provide default/fallback labeling

- Allow external labeling (IPsec, CIPSO) to override the secmark labels

This gives us loopback labeling, the ability to retain the general usability of only local iptables-based labeling, and a very simple mechanism for integrating external labeling.

Does this address all of your requirements ?

If not, please explain what's missing.

(why couldn't this have all waited a bit...)

Quoted 1 line · Darrel Goeddel

(why couldn't this have all waited a bit...)

Paul is addressing a real need. Like many things that really need doing and take time, multiple people are simultaneously working on it.

I installed the netlabel patches and have tested them with good results in MLS/permissive at a few levels (s0, s2:c0.c253, s2:c0.c253). More testing to follow.

netlabelctl unlbl add interface:eth0 address:10.211.55.8/32 label:user_u:object_r:user_t:s2:c0.c253

/netlabelctl unlbl list
accept:on
interface:eth0,address:
192.168.20.253/32,label:"user_u:object_r:user_t:s0" interface:eth0,address:
10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

This is a big improvement in linux labeled networking functionality.

Quoted 5 lines

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

This is a big improvement in linux labeled networking functionality.

As described in an earlier email, from my not-yet-full grasp on the patch, this is a vulnerability waiting to happen in the event of using netlabel fallback contexts alongside labeled ipsec.

That is not an improvement.

Quoted 5 lines · Darrel Goeddel

Quoted 5 lines

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

Quoted 7 lines

Quoted 1 line

This is a big improvement in linux labeled networking functionality.

As described in an earlier email, from my not-yet-full grasp on the patch,
this is a vulnerability waiting to happen in the event of using netlabel
fallback contexts alongside labeled ipsec.

Which would be a configuration error. There are lots of dangerous but useful tools (rm, dd). I have ipsec and netlabel configured. I'll try crossing the streams and see if we get total protonic reversal.

Quoted 1 line

That is not an improvement.

We will have to disagree. It is a big improvement in functionality. It may not be the final approach, but it is the only one I can evaluate today.

Quoted 11 lines · Darrel Goeddel

Quoted 6 lines

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

This is a big improvement in linux labeled networking functionality.

As described in an earlier email, from my not-yet-full grasp on the patch,
this is a vulnerability waiting to happen in the event of using netlabel
fallback contexts alongside labeled ipsec.

Which would be a configuration error. There are lots of dangerous but useful tools (rm, dd). I have ipsec and netlabel configured. I'll try crossing the streams and see if we get total protonic reversal.

Quoted 1 line

That is not an improvement.

We will have to disagree. It is a big improvement in functionality. It may not be the final approach, but it is the only one I can evaluate today.

Agreed.  If the "fallback" context wouldn't actually replace a real peer context supplied by the peer itself, this would be useful.  I'm sure it can be made to operate this way if this patch set would be deemed the way-to-go in the end.

Quoted 20 lines · Joe Nall

Quoted 1 line · Darrel Goeddel

(why couldn't this have all waited a bit...)

Paul is addressing a real need. Like many things that really need doing and take time, multiple people are simultaneously working on it.

I installed the netlabel patches and have tested them with good results in MLS/permissive at a few levels (s0, s2:c0.c253, s2:c0.c253). More testing to follow.

netlabelctl unlbl add interface:eth0 address:10.211.55.8/32 label:user_u:object_r:user_t:s2:c0.c253

/netlabelctl unlbl list
accept:on
interface:eth0,address:
192.168.20.253/32,label:"user_u:object_r:user_t:s0" interface:eth0,address:
10.211.55.8/32,label:"user_u:object_r:user_t:s2:c0.c253"

Quoted 5 lines

getpeercon() returned 'user_u:object_r:user_t:C O N F I D E N T I A L'

for a connection from 10.211.55.8.

This is a big improvement in linux labeled networking functionality.

As described in an earlier email, from my not-yet-full grasp on the patch, this is a vulnerability waiting to happen in the event of using netlabel fallback contexts alongside labeled ipsec. That is not an improvement. If there were consistency checks between the various forms of external labels, this would not be an issue and the functionality would indeed be an improvement. Again, I do not have a test case, but Paul's response to my query about getpeercon returning a netlabel modified version of the xfrm label seemed to validate my concern.

Because of the position I am in (needing to find something workable for actual
users), I have been trying to get my head aounrd the state of SELinux networking,
the ideas that have been talked about in the past, and how we can prevent the
SELinux networking infrastructure from resembling a Rube-Goldberg machine. I'll
be presenting some of the problems I perceive along with some very high level
ideas early next week.

Quoted 7 lines · Darrel Goeddel

Because of the position I am in (needing to find something workable for actual
users), I have been trying to get my head around the state of SELinux networking,
the ideas that have been talked about in the past, and how we can prevent the
SELinux networking infrastructure from resembling a Rube-Goldberg

Quoted 4 lines

I'll
be presenting some of the problems I perceive along with some very high level
ideas early next week.

Such a tease! ;)

I assume from other, previous discussions you are currently using the secid-reconciliation patches?

Quoted 7 lines · Darrel Goeddel

Because of the position I am in (needing to find something workable for actual
users), I have been trying to get my head aounrd the state of SELinux networking,
the ideas that have been talked about in the past, and how we can prevent the
SELinux networking infrastructure from resembling a Rube-Goldberg

Quoted 4 lines

I'll
be presenting some of the problems I perceive along with some very high level
ideas early next week.

Such a tease! ;)

picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
(when commenting, please refrain from belittling my artistic skills)

- A new SECFILTER iptables module is in place to perform flow control checks. Just as we have used the expressiveness (either fine grained or coarse grained - your choice) of iptables to define fallback labels for packets based on their attributes, we want to be able to define access check based on those attributes. It is here where we can say that only http_client_t can get to port 80 on this machine, or that only a secret packet can leave the machine through the eth1 device. The SECFILTER mechanism will be able to distinguish controls for incoming, outgoing, and forwarded traffic. In the absence of a matching "target context" from SECFILTER, the secmark will be checked against the unlabeled context (no SECFILTER - no label).

Quoted 2 lines · Darrel Goeddel

picture here: http://home.insightbb.com/~dgoeddel/networking/simple.png
(when commenting, please refrain from belittling my artistic skills)

I think this looks good in terms of labeling via secmark, although it hides external labeling.

Quoted 11 lines

- A new SECFILTER iptables module is in place to perform flow control checks. Just as we have used the expressiveness (either fine grained or coarse grained - your choice) of iptables to define fallback labels for packets based on their attributes, we want to be able to define access check based on those attributes. It is here where we can say that only http_client_t can get to port 80 on this machine, or that only a secret packet can leave the machine through the eth1 device. The SECFILTER mechanism will be able to distinguish controls for incoming, outgoing, and forwarded traffic. In the absence of a matching "target context" from SECFILTER, the secmark will be checked against the unlabeled context (no SECFILTER - no label).

This seems problematic. The secmark model is currently based upon iptables rules being used to classify and label traffic, with access control performed within SELinux based upon those labels and permission types. So, the access control decisions are performed via the AVC and according to SELinux policy.

In the case of local labeling, the packet is labeled based upon the port (and any other iptables selector), so you don't need to have a separate mechanism i.e. the packet will only be labled as http_client_t if it's leaving via port 80 and also part of a validated connection.

Not sure what the answer is for applying controls to externally labeled packets.

It seems like a special case, though, and that typically, the network interface is the only thing you really want to check here. If so,

perhaps we implement a secmark (packet label) vs. netif check once external labeling has been applied.

So, the packet control permissions using secmark would be something like:

socket layer : send, recv

network layer : flow_in, flow_forward, flow_out
link layer : netif_in, netif_out

I think this will make sense to users due to the layering, and separation of labeling and access control.

The order of mediation is:

Inbound to local:

   netif_in -> flow_in -> recv

Forward:

   netif_in -> flow_forward -> netif_out

Outbound from local:

   send -> flow_out -> netif_out

Now, labeling is not so simple :-)

We have local labeling via secmark, which needs to be applied first and then potentially overridden.

Then we have two differnt forms of external labeling, with differing mechanisms and policy constructs.

For general and non-legacy users, we need to be focused on IPsec labeling.

I'm not sure what the answer is for making it more usable at this stage, although if we don't make significant improvements, people will never use it. Any bright ideas? :-)

The recv check at the socket layer becomes socket (proxy for local process)
receiving information from the secmark (peer process). This process vs. process style check didn't seem to have a natural fit with sending the information because the peer isn't as well known as it could be in the receive case. For this reason, send is actually absent in this idea right now.
If there were a process vs. process check on send the peer process could only
be identified through the SECMARK fallback labels.

There's that darn send again... The flow_out check from SECFILTER is really performing the duties of the current send operation.

- a packet goes though "filter points", the packet is the subject and the "filter point" is the object it must pass through (these filters happen at input, output, and forwarding)

- a socket reading a packet must be able to listen to the peer that created it - a slightly new meaning for current socket vs. secmark access check

Quoted 10 lines · Darrel Goeddel

The recv check at the socket layer becomes socket (proxy for local process)
receiving information from the secmark (peer process). This process vs. process style check didn't seem to have a natural fit with sending the information because the peer isn't as well known as it could be in the receive case. For this reason, send is actually absent in this idea right now.
If there were a process vs. process check on send the peer process could only
be identified through the SECMARK fallback labels.

Perhaps I'm missing something, but the send check is necessary for e.g. "can a httpd_server_t socket send an smtp_client_t packet" ?

What you're calling fallback labels will likely be the only labels a normal user encounters.

Quoted 2 lines

There's that darn send again... The flow_out check from SECFILTER is really performing the duties of the current send operation.

I think there's a slight misunderstanding here. I'm proposing not having SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.

Discussion of security gates and similar I think will really confuse people, as will the idea of labeling such abstract entities, which is heading down a similar path to earlier proposals on this topic.

Quoted 3 lines

- a packet goes though "filter points", the packet is the subject and the "filter point" is the object it must pass through (these filters happen at input, output, and forwarding)

What they really are is the boundary of network layer of the machine, which is to say, the boundary of machine itself in terms of network functionality. i.e. once a packet is accepted into the IP stack, it can be forwarded, delivered etc.

So, allowing flow_in means "the packet can flow into this machine", and similar for flow_forward and flow_out.

The socket recv/send checks are against the endpoint (at least, as delegated by an authorized endpoint via the socket).

The netif_in and netif_out allow checking of the packet flowing across specific physical interfaces.

I don't think we need to add any new abstractions here, and these should be understandable by people who can configure networking.

Quoted 3 lines

- a socket reading a packet must be able to listen to the peer that created it - a slightly new meaning for current socket vs. secmark access check

I'm not sure what this means.

Quoted 3 lines

Perhaps I'm missing something, but the send check is necessary for e.g. "can a httpd_server_t socket send an smtp_client_t packet" ?

The send check would be necessary for that particular type of check. In the proposed scheme, that particular question would never arise. The skb is merely an extension of the socket, much as the socket is an extension of the process. The question is now "can httpd_server_t flow_out of an smtp_t network entity?" I'm having trouble coming up with nice terminology for that one. How's this for the question - "can an httpd_server_t packet go to a destination with certain characteristics?"

Quoted 2 lines

What you're calling fallback labels will likely be the only labels a normal user encounters.

That is correct. In the absence of labeled network (just about all cases), the SECMARK facility will provide the label of the peer.

Quoted 5 lines

Quoted 2 lines

There's that darn send again... The flow_out check from SECFILTER is really performing the duties of the current send operation.

I think there's a slight misunderstanding here. I'm proposing not having SECFILTER at all, and instead adding netif_in and netif_out SELinux hooks.

That would provide flow control only at the interface level. That is certainly better than the current lack of flow control ability, but it does not offer the flexibility of the iptables mechanism.

It also gives us
different controls over forwarded traffic. Instead of the ability of the unique forward check that SECFILTER would provide, we are limited to using the in and out netif checks. We can no longer say that sysadm_t traffic can come into the machine, sysadm_t traffic can go out of the machine, but sysadm_t traffic can not pass through the machine.

Quoted 3 lines

Discussion of security gates and similar I think will really confuse people, as will the idea of labeling such abstract entities, which is heading down a similar path to earlier proposals on this topic.

I think a lot of the previous confusion came from some of the following points:

- trying to use secmark as BOTH an implicit fallback context AND a flow control point
- the transitions from secmark to xfrm to NetLabel, etc., that were thrown in to allow domain->packet->domain

I'm avoiding those issues with these simple rules:

- SECMARK is used only for establishing a fallback context for the peer

- SECFILTER is used only for performing the flow control checks

- the packet always carries the peer's context, not a data context

Quoted 10 lines

Quoted 4 lines

- a packet goes though "filter points", the packet is the subject and the "filter point" is the object it must pass through (these filters happen
at input, output, and forwarding)

What they really are is the boundary of network layer of the machine, which is to say, the boundary of machine itself in terms of network functionality. i.e. once a packet is accepted into the IP stack, it can be forwarded, delivered etc.

Quoted 5 lines

So, allowing flow_in means "the packet can flow into this machine", and similar for flow_forward and flow_out.

The socket recv/send checks are against the endpoint (at least, as delegated by an authorized endpoint via the socket).

The recv check makes sense. The socket is getting a packet from peer peer_domain_t:secret, can the socket read that in? The label of peer_domain_t:secret came from the SECMARK mechanism which arrived at that label based on the characteristics of the sender. The peer_domain_t:secret could have just as easily been explicitly conveyed by the sender.

Does it make sense to make that check for outgoing traffic? There is no way to have peer-provided information about the receiver, you only know where the info is going, not who will actually get it. Yes, I understand that I double standard here because I somehow believe that the src characteristics for incoming packets are more useful than the dst characteristics for outgoing packets. I don't love outgoing packets any less - I am giving the incoming more credibility because there _can_ be real information about the context in that case.

Using SECMARK for the target of the outgoing access check means that we are back to needing another place to store the "target" info in the skb,

SECFILTER really is doing the same job for outgoing traffic as the current usage of SECMARK, the only difference is that the subject comes from the skb (same as the socket for locally generated traffic) and the decision is made in the SECFILTER module, not delayed (which needs storage) until later.

I'll bang my head around here to see what kind of functionality would be missing (as opposed to the SECMARK/SECFILTER combo) with what you are suggesting. I'll try to come up with some diagrams for the different methods that are being discussed to make sure we are on the same page. Since you are going for "no SECFILTER", how are you envisioning the network layer checks you described before being (flow_in, flow_forward, flow_out) handled? Or are you saying the idea should go, not just the SECFILTER way of doing it?

Quoted 7 lines

The netif_in and netif_out allow checking of the packet flowing across specific physical interfaces.

I don't think we need to add any new abstractions here, and these should be understandable by people who can configure networking.

Quoted 5 lines

Quoted 3 lines

- a socket reading a packet must be able to listen to the peer that created it - a slightly new meaning for current socket vs. secmark access check

I'm not sure what this means.

The socket vs. secmark check conceptually means "can the local process read this type of information" right now.

By having the secmark field
always convey the context of the peer, the check takes on a slightly different meaning - "can the local process read information written by the peer process?".

implementation convenience/cleanliness but it requires either a reduction in the system's SID space from 32 bits to 16 bits (4.<mumble> billion unique labels down to 65 thousand unique labels for all subjects/objects on the system) or some sort of additional internal SID mapping mechanism which has yet to be defined.

For those of you who are still paying attention to this thread you may have been wondering why it went quiet all of a sudden; well, the thread didn't go quiet, it went off-list.

...

* Packet labels (one or two)

... voting to continue with the two packet labels as they currently exist.

One thing that did arise during the discussion was the slow realization that the names for the two packet labels are probably not as descriptive as they should be and that has most likely led to a certain amount of confusion. In an effort to help make the two different label types more clear it was decided to start calling the external labels "peer labels" as the external label always represents the label of the peer who originated the packet and it's data. It was also decided to start calling the internal labels "secmark

labels", while the compat_net mechanism still exists it is deprecated in favor of the SECMARK mechanism which is the only way to set/manipulate the internal label.

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the traditional firewall rules with SELinux mandatory access controls.

The
secmark labels allow policy writers and security administrators to meet security goals similar to the following:
"Only allow Apache to accept connections over tcp/80 from
192.168.0.0/24, restricting it to my local network and not the Big-Bad-Internet."
-- or --
"Only allow a particular instance of Firefox to connect to
1.2.3.4 over tcp/443, restricting it to my online banking site."

Peer, or external, labels, furnished by NetLabel or labeled IPsec/XFRM, provide the domain/context/label of the process which generated the packet/data.

The external labels allow policy writers and security administrators to meet security goals similar to the following:
"This instance of Apache serves sensitive financial data and
I only want specific clients/peers/domains to be able to access the data from this Apache instance."
-- or --
"I want to ensure that users connecting to the login server over
a Secret connection run in a Secret domain."

* Splitting the SECMARK field

After it was agreed to continue using both the peer and secmark labels the discussion turned to how best to propagate those labels with the packet. As you probably know there is a 32 bit field already in the packet/sk_buff structure which is currently used exclusively by the secmark label. Once again, there were two approaches considered. The first was the continuation of the status quo where the secmark label is determined by looking directly at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is

determined through a function call with the sk_buff as an argument, "peer_label(sk_buff)".

The second idea was to divide the secmark ... the potential for introducing compatibility problems.

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it

would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4

packets. Labeled IPsec can convey the full SELinux label/context of the peer

for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

The solution for this problem is tightly coupled with the decision to split/not-split the secmark field in the sk_buff structure. If the secmark field were split then the peer label could be set directly in the packet to the originating socket and then preserved across the loopback pseudo-interface for use on the receiving/inbound side. However, this does require splitting the secmark field and all that goes along with it (see above). If the secmark field were not split then the solution is to continue

to develop the peer labeling mechanisms to support loopback labeling. Joy Latten from IBM has been working on better support for IPsec over loopback (although I'm not sure of it's current status) and I am steadily working towards a more full featured NetLabel which would be able to convey a full SELinux context over the wire/loopback.

* Packet flow control

...

* Fallback labels

The simple idea that started this whole discussion. The need for a usable peer label fallback mechanism is understood by everyone but the granularity with which peer fallback labels are assigned are still a source of debate. The idea is wether the granularity proposed in this NetLabel patchset which allows per-host/subnet granularity for each interface is enough, and if not is a very granular iptables/netfilter peer label assignment of fallback labels required? This topic did come up briefly some time ago on the public mailing list between Joshua Brindle and myself and we agreed that the granularity presented in this patchset is sufficient, however, not everyone feels this way so we are still discussing the best solution.

As part of the peer fallback label discussion it became apparent to everyone that better integration/cooperation between the NetLabel and XFRM labeling mechanisms is needed. The strict separation worked well in the beginning but

as we start to develop a richer set of functionality the two labeling mechanisms need to work better together to ensure the consistency of the network access controls. If the approach put forward in this patch set is agreed upon as the right way to solve the peer fallback problem I will be modifying it to take into account XFRM labels so that the NetLabel provided fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO

label on the packet. Further, work will be done to ensure that when both a XFRM and NetLabel/CIPSO label are present on an incoming packet that the labels are the same, otherwise the packet will be dropped/rejected.

Quoted 3 lines · --- Paul Moore

For those of you who are still paying attention to this thread you may have been wondering why it went quiet all of a sudden; well, the thread didn't go quiet, it went off-list.

Boo.

Quoted 10 lines

One thing that did arise during the discussion was the slow realization that the names for the two packet labels are probably not as descriptive as they should be and that has most likely led to a certain amount of confusion. In an effort to help make the two different label types more clear it was decided to start calling the external labels "peer labels" as the external label always represents the label of the peer who originated the packet and it's data. It was also decided to start calling the internal labels "secmark labels", while the compat_net mechanism still exists it is deprecated in favor of the SECMARK mechanism which is the only way to set/manipulate the internal label.

Hmm. In one case the name reflects the purpose (label of peer) and in the other the name reflects the mechanism (label used in SECMARK). I like the clarification of the former as it tells an LSM writer what to use the label for, while I dislike the latter because it does nothing to help me understand the intent of the mechanism.

Quoted 4 lines

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the traditional firewall rules with SELinux mandatory access controls.

Is it really intended that Secmark is an SELinux specific mechanism?

Yes, yes, I understand that SELinux is the only upstream LSM and all that. If it is intended only as a component of SELinux going forward regardless of alternative LSM availability maybe that should be more explicit in the related documentation.

I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that is of course your call.

Quoted 11 lines

* Splitting the SECMARK field

After it was agreed to continue using both the peer and secmark labels the discussion turned to how best to propagate those labels with the packet. As you probably know there is a 32 bit field already in the packet/sk_buff structure which is currently used exclusively by the secmark label. Once again, there were two approaches considered. The first was the continuation of the status quo where the secmark label is determined by looking directly at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is

Quoted 2 lines

determined through a function call with the sk_buff as an argument, "peer_label(sk_buff)".

Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff), or security_peer_label(sk_buff)?

Quoted 15 lines

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it

would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4

packets. Labeled IPsec can convey the full SELinux label/context of the peer

Quoted 2 lines

for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

In the early Smack development I experimented with a scheme that was very like CIPSO with the exception that it carried the MAC information directly.

That would be a smack_t for me, but it would do u32s just fine.

It has the disadvantage that you have to be careful to avoid going off the box since there's no RFC supporting it.

I seem to recall there is an "approved" scheme lurking in the networking header files, but I never persued that.

Quoted 9 lines

The solution for this problem is tightly coupled with the decision to split/not-split the secmark field in the sk_buff structure. If the secmark field were split then the peer label could be set directly in the packet to the originating socket and then preserved across the loopback pseudo-interface for use on the receiving/inbound side. However, this does require splitting the secmark field and all that goes along with it (see above). If the secmark field were not split then the solution is to continue

Quoted 5 lines

to develop the peer labeling mechanisms to support loopback labeling. Joy Latten from IBM has been working on better support for IPsec over loopback (although I'm not sure of it's current status) and I am steadily working towards a more full featured NetLabel which would be able to convey a full SELinux context over the wire/loopback.

So how big is a "full" context?

Quoted 27 lines

* Fallback labels

The simple idea that started this whole discussion. The need for a usable peer label fallback mechanism is understood by everyone but the granularity with which peer fallback labels are assigned are still a source of debate. The idea is wether the granularity proposed in this NetLabel patchset which allows per-host/subnet granularity for each interface is enough, and if not is a very granular iptables/netfilter peer label assignment of fallback labels required? This topic did come up briefly some time ago on the public mailing list between Joshua Brindle and myself and we agreed that the granularity presented in this patchset is sufficient, however, not everyone feels this way so we are still discussing the best solution.

As part of the peer fallback label discussion it became apparent to everyone that better integration/cooperation between the NetLabel and XFRM labeling mechanisms is needed. The strict separation worked well in the beginning but

as we start to develop a richer set of functionality the two labeling mechanisms need to work better together to ensure the consistency of the network access controls. If the approach put forward in this patch set is agreed upon as the right way to solve the peer fallback problem I will be modifying it to take into account XFRM labels so that the NetLabel provided fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO

Quoted 3 lines

label on the packet. Further, work will be done to ensure that when both a XFRM and NetLabel/CIPSO label are present on an incoming packet that the labels are the same, otherwise the packet will be dropped/rejected.

It makes me uncomfortable to hear you say that XFRM is SELinux specific and that it needs to be integrated with NetLabel, which currently isn't.

I know that Smack isn't upstream yet.

Nonetheless, I would hate to see
underlying mechanisms that currently provide useful facilities become SELinux specific.

Feel free to suggest something better, I don't think anyone was ever really in love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

Quoted 3 lines · Paul Moore

Feel free to suggest something better, I don't think anyone was ever really in love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

I like packet label, because it's a label based on the attributes of the packet.

Quoted 6 lines · James Morris

Quoted 4 lines · Paul Moore

Feel free to suggest something better, I don't think anyone was ever really in love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

Quoted 3 lines

I like packet label, because it's a label based on the attributes of the packet.

[Sorry, I forgot about this suggestion when replying]

I was always a little nervous that just the term "packet label" would get confusing ... are we talking about the "peer" packet label or the "packet" packet label ... but I see your point.

What do other people think? I know you've got an opinion Casey ...

Quoted 5 lines

Hmm. In one case the name reflects the purpose (label of peer) and in the other the name reflects the mechanism (label used in SECMARK). I like the clarification of the former as it tells an LSM writer what to use the label for, while I dislike the latter because it does nothing to help me understand the intent of the mechanism.

Feel free to suggest something better, I don't think anyone was ever really in
love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

Quoted 6 lines

Quoted 5 lines

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the traditional firewall rules with SELinux mandatory access controls.

Quoted 1 line

Is it really intended that Secmark is an SELinux specific mechanism?

I don't see why it _has_ to be a SELinux specific mechanism. I understand that some of the netfilter code is SELinux specific (mostly the part dealing with SELinux secctx/secid conversions) but you could either change that to the more generic LSM secctx/secid conversion API or simply augment it for SMACK (I even see some nice case statements already in place to make things easy for you).

However, all of this assumes that the LSM has a functional label-to-32bit-token mapping mechanism similar to what SELinux has with the SID concept. I know, and understand why, you are not a big fan of this for SMACK but secids/tokens are a reality in several parts of the kernel and I don't expect that to change anytime soon. You don't have to implement a label/token mapping mechanism I guess, but you won't be able to make use of kernel subsystems which require it.

Quoted 4 lines

Yes, yes, I understand that SELinux is the only upstream LSM and all that. If it is intended only as a component of SELinux going forward regardless of alternative LSM availability maybe that should be more explicit in the related documentation.

Documentation? Who has documentation?! ;)

You make a good point, one that became clear to me over the course of the discussion is that we need better documentation about the SELinux/LSM network

access controls work in the kernel. Josh wrote up a nice blog entry a while ago about how to make some of it work in userspace (no NetLabel instructions,

though ... tsk tsk <g>!) but we don't have anyting for kernel hack[er]s. One

of the things that made it on to my todo list (but I haven't shared this with

anyone until now) is a document/wiki-entry describing how things work in the kernel, and I'll be sure to point out which things are SELinux specific (which is pretty few, if any).

Quoted 3 lines

I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that is of course your call.

As long as their is an LSM my opinion is that all mechanisms which live outside the LSM and/or provide services to LSM modules should be agnostic of any one particular LSM. However, this does not mean that the is must deal only with binary/string/secctx labels; if it makes sense to deal strictly with secid tokens then so be it.

Quoted 11 lines

Quoted 11 lines

* Splitting the SECMARK field

After it was agreed to continue using both the peer and secmark labels the discussion turned to how best to propagate those labels with the packet. As you probably know there is a 32 bit field already in the packet/sk_buff structure which is currently used exclusively by the secmark label. Once again, there were two approaches considered. The first was the continuation of the status quo where the secmark label is determined by looking directly at the secmark field in the sk_buff, "sk_buff.secmark", and the peer label is

Quoted 5 lines

Quoted 2 lines

determined through a function call with the sk_buff as an argument, "peer_label(sk_buff)".

Would that be netlbl_peer_label(sk_buff), selinux_peer_label(sk_buff), or security_peer_label(sk_buff)?

At this point I'm thinking this would be internal/specific to the LSM; SMACK and other LSMs cand devise whatever internal mechanism they want. SMACK for example only has one labeling mechanism that I can see so this is kind of a moot point for you, just make use of the NetLabel API to get the security attributes/label of a packet. For SELinux it's not quite so simple as both NetLabel and XFRM can provide peer label information, in order to make it easier I was suggesting providing a single wrapper function that would take into account all peer labeling mechanisms and return the correct peer label.

Quoted 15 lines

Quoted 15 lines

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it

would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4

packets. Labeled IPsec can convey the full SELinux label/context of the peer

Quoted 6 lines

Quoted 2 lines

for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

In the early Smack development I experimented with a scheme that was very like CIPSO with the exception that it carried the MAC information directly.

I am thinking along the same lines for NetLabel/CIPSO, similar to the old Selopt concept. I'm also considering adding some additional fields/info to carry additional information that used to passed along via MaxSix/SAMP; more on that when I get to that work item.

Quoted 1 line

That would be a smack_t for me, but it would do u32s just fine.

While having to deal only with secids would make life easier, it might be possible to offer alternate option formats for different LSMs (as long as they were in mainline).

Quoted 2 lines

It has the disadvantage that you have to be careful to avoid going off the box since there's no RFC supporting it.

Yes, indeed. Although in the case of NetLabel/CIPSO we have the wonderful (well, not so wonderful if your a router vendor) FIPS defined "freeform" tag which would allow us to stuff whatever we want so long as it fits in the IP header length limitations. That said, I'm currently tossing around ways to leverage the ip_build_options() routine to provide destination specific NetLabel labeling in conjunction with the existing per-domain labeling.

IPv6 is of course, a different story.

Quoted 2 lines

I seem to recall there is an "approved" scheme lurking in the networking header files, but I never persued that.

I have absolutely no idea what you are talking about here.

Quoted 15 lines

Quoted 14 lines

The solution for this problem is tightly coupled with the decision to split/not-split the secmark field in the sk_buff structure. If the secmark field were split then the peer label could be set directly in the packet to the originating socket and then preserved across the loopback pseudo-interface for use on the receiving/inbound side. However, this does require splitting the secmark field and all that goes along with it (see above). If the secmark field were not split then the solution is to continue

to develop the peer labeling mechanisms to support loopback labeling. Joy Latten from IBM has been working on better support for IPsec over loopback (although I'm not sure of it's current status) and I am steadily working towards a more full featured NetLabel which would be able to convey a full SELinux context over the wire/loopback.

Quoted 1 line

So how big is a "full" context?

See my comments above. In the case of SELinux I would probably simply just pass the SID directly over loopback for performance reasons.

Quoted 11 lines

Quoted 8 lines

* Fallback labels

...

label on the packet. Further, work will be done to ensure that when both a XFRM and NetLabel/CIPSO label are present on an incoming packet that the labels are the same, otherwise the packet will be dropped/rejected.

It makes me uncomfortable to hear you say that XFRM is SELinux specific and that it needs to be integrated with NetLabel, which currently isn't.

Relax, I plan on making the integration/cooperation within SELinux. I'm still
working on the patches (just started thinking/coding yesterday) but as it stands the only real change to NetLabel will be the addition of label source information in the netlbl_lsm_secattr struct, i.e. is this a CIPSO label, a unlabeled/fallback label, etc.

Quoted 1 line

I know that Smack isn't upstream yet.

Slacker :)

Quoted 3 lines

Nonetheless, I would hate to see
underlying mechanisms that currently provide useful facilities become SELinux specific.

As long as the LSM is in place, so would I.

Quoted 6 lines · --- Paul Moore

Quoted 5 lines

Hmm. In one case the name reflects the purpose (label of peer) and in the other the name reflects the mechanism (label used in SECMARK). I like the clarification of the former as it tells an LSM writer what to use the label for, while I dislike the latter because it does nothing to help me understand the intent of the mechanism.

Quoted 4 lines

Feel free to suggest something better, I don't think anyone was ever really in
love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

It does because it describes the intended use.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the traditional firewall rules with SELinux mandatory access controls.

Quoted 8 lines

Quoted 1 line

Is it really intended that Secmark is an SELinux specific mechanism?

I don't see why it _has_ to be a SELinux specific mechanism. I understand that some of the netfilter code is SELinux specific (mostly the part dealing with SELinux secctx/secid conversions) but you could either change that to the more generic LSM secctx/secid conversion API or simply augment it for SMACK (I even see some nice case statements already in place to make things easy for you).

I can see where the mechanism is intended for generality and where there is strong SELinux influence. I always get nervous when what looks like a general mechanism is described in terms of a specific use to which it gets put.

Quoted 4 lines

Quoted 3 lines

I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that is of course your call.

Quoted 5 lines

As long as their is an LSM my opinion is that all mechanisms which live outside the LSM and/or provide services to LSM modules should be agnostic of any one particular LSM. However, this does not mean that the is must deal only with binary/string/secctx labels; if it makes sense to deal strictly with secid tokens then so be it.

Maybe we can fix that in 3.0. That is, I'll accept it for now, but someday we really ought to revisit the decision.

Quoted 27 lines

Quoted 15 lines

Quoted 15 lines

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it

would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4

packets. Labeled IPsec can convey the full SELinux label/context of the peer

Quoted 6 lines

Quoted 2 lines

for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

In the early Smack development I experimented with a scheme that was very like CIPSO with the exception that it carried the MAC information directly.

I am thinking along the same lines for NetLabel/CIPSO, similar to the old Selopt concept. I'm also considering adding some additional fields/info to carry additional information that used to passed along via MaxSix/SAMP; more on that when I get to that work item.

Quoted 5 lines

Quoted 1 line

That would be a smack_t for me, but it would do u32s just fine.

While having to deal only with secids would make life easier, it might be possible to offer alternate option formats for different LSMs (as long as they were in mainline).

Well, you could define the interface to take a pointer and length, thereby leaving it up to the LSM.

Quoted 12 lines · Casey Schaufler

Quoted 10 lines · --- Paul Moore

Quoted 5 lines

Hmm. In one case the name reflects the purpose (label of peer) and in the other the name reflects the mechanism (label used in SECMARK). I like the clarification of the former as it tells an LSM writer what to use the label for, while I dislike the latter because it does nothing to help me understand the intent of the mechanism.

Feel free to suggest something better, I don't think anyone was ever really in
love with the term "secmark label". I believe at one point Stephen suggested "iptables label", does that sound any better?

Quoted 1 line

It does because it describes the intended use.

Actually, after reading Josh's mail I'm now thinking "netfilter label" is probably a better choice.

After all, the bikeshed will need to be repainted
in a few years ... ;)

Quoted 15 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

As a reminder, below is a definition of the two types of labels.

Secmark, or internal, labels are essentially a means for integrating the traditional firewall rules with SELinux mandatory access controls.

Quoted 8 lines

Quoted 1 line

Is it really intended that Secmark is an SELinux specific mechanism?

I don't see why it _has_ to be a SELinux specific mechanism. I understand that some of the netfilter code is SELinux specific (mostly the part dealing with SELinux secctx/secid conversions) but you could either change that to the more generic LSM secctx/secid conversion API or simply augment it for SMACK (I even see some nice case statements already in place to make things easy for you).

Quoted 4 lines

I can see where the mechanism is intended for generality and where there is strong SELinux influence. I always get nervous when what looks like a general mechanism is described in terms of a specific use to which it gets put.

Then channel some of that nervous energy into some patches :) Really, I think
you could probably "fix" some of this without affecting the user visible portion of it ... but then again I haven't thought about it for that long.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

I would personally be
disappointed if the mechanism were unavailable to other LSMs, but that is of course your call.

Quoted 8 lines

Quoted 5 lines

As long as their is an LSM my opinion is that all mechanisms which live outside the LSM and/or provide services to LSM modules should be agnostic of any one particular LSM. However, this does not mean that the is must deal only with binary/string/secctx labels; if it makes sense to deal strictly with secid tokens then so be it.

Maybe we can fix that in 3.0. That is, I'll accept it for now, but someday we really ought to revisit the decision.

Sure, in a perfect world we would have void pointers everywhere, with a well defined set of lifecycle management hooks that would enable us to do whatever

we wanted in terms of labeling objects on the system. It's a nice idea, scratch that, a truly awesome idea, but I just don't see that happening in the near future.

Quoted 27 lines

Quoted 27 lines

Quoted 15 lines

Quoted 15 lines

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it

would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4

packets. Labeled IPsec can convey the full SELinux label/context of the peer

Quoted 6 lines

Quoted 2 lines

for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

In the early Smack development I experimented with a scheme that was very like CIPSO with the exception that it carried the MAC information directly.

I am thinking along the same lines for NetLabel/CIPSO, similar to the old Selopt concept. I'm also considering adding some additional fields/info to carry additional information that used to passed along via MaxSix/SAMP; more on that when I get to that work item.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

That would be a smack_t for me, but it would do u32s just fine.

While having to deal only with secids would make life easier, it might be possible to offer alternate option formats for different LSMs (as long as they were in mainline).

Well, you could define the interface to take a pointer and length, thereby leaving it up to the LSM.

Yes, that is one of the things I'm considering but one of the drawbacks to this approach is that it makes commonality between LSMs very hard.

We can talk more about the exact functionality/API later if you would like, right now I think we should stick to the topics in the original email so we don't get stuck in a rathole. My plan is to start looking into this after the fallback label issue is resolved.

Quoted 2 lines · --- Paul Moore

as we start to develop a richer set of functionality the two labeling mechanisms need to work better together to ensure the consistency of the network access controls. If the approach put forward in this patch set is agreed upon as the right way to solve the peer fallback problem I will be modifying it to take into account XFRM labels so that the NetLabel provided fallback peer label will only be used when there is no XFRM or NetLabel/CIPSO

Quoted 2 lines

label on the packet. Further, work will be done to ensure that when both a XFRM and NetLabel/CIPSO label are present on an incoming packet that the labels are the same, otherwise the packet will be dropped/rejected.

It makes me uncomfortable to hear you say that XFRM is SELinux specific and that it needs to be integrated with NetLabel, which currently isn't. I know that Smack isn't upstream yet. Nonetheless, I would hate to see underlying mechanisms that currently provide useful facilities become SELinux specific.

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4 packets. Labeled IPsec can convey the full SELinux label/context of the peer for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

The solution for this problem is tightly coupled with the decision to split/not-split the secmark field in the sk_buff structure. If the secmark field were split then the peer label could be set directly in the packet to the originating socket and then preserved across the loopback pseudo-interface for use on the receiving/inbound side. However, this does require splitting the secmark field and all that goes along with it (see above). If the secmark field were not split then the solution is to continue to develop the peer labeling mechanisms to support loopback labeling. Joy Latten from IBM has been working on better support for IPsec over loopback (although I'm not sure of it's current status) and I am steadily working towards a more full featured NetLabel which would be able to convey a full SELinux context over the wire/loopback.

Paul Moore wrote:

<snip>

Quoted 13 lines

* Loopback/Localhost peer packet labeling

This has been a long standing requirement which at first glance seems like it would be simple to achieve but in practice it has proven quiet difficult to implement. Current solutions to the problem involve using either NetLabel/CIPSO or labeled IPsec over loopback to provide peer labels, unfortunately both have drawbacks. NetLabel/CIPSO is currently limited to only conveying the MLS sensitivity label over the wire and only then for IPv4 packets. Labeled IPsec can convey the full SELinux label/context of the peer for both IPv4 and IPv6 but is difficult to configure and introduces unnecessary overhead for packets that never leave the machine.

Quoted 12 lines

The solution for this problem is tightly coupled with the decision to split/not-split the secmark field in the sk_buff structure. If the secmark field were split then the peer label could be set directly in the packet to the originating socket and then preserved across the loopback pseudo-interface for use on the receiving/inbound side. However, this does require splitting the secmark field and all that goes along with it (see above). If the secmark field were not split then the solution is to continue to develop the peer labeling mechanisms to support loopback labeling. Joy Latten from IBM has been working on better support for IPsec over loopback (although I'm not sure of it's current status) and I am steadily working towards a more full featured NetLabel which would be able to convey a full SELinux context over the wire/loopback.

I just want to note that there are a few associated changes that should go along with this. Once we have the concept of the sender's context in in/associated with (I prefer in :)) the skb, we should use that when applying on-the-wire labels. For the case fo locally generated packets, this end up doing the same thing since the socket's label is in the skb as the peer label. The real difference in behavior is the added functionality of putting labels on the wire for forwarded packets (if prescribed by the on-the-wire policy). For instance, a packet which receives a fallback label of SECRET (because it came in a interface we treat as SECRET) would be given the opportunity to exit a different interface with that SECRET label on-the-wire. This gives us the ability to "consolidate" single level networks into a single network that uses explicit labeling. Should work nicely for cipso and labeled ipsec This is something we currently employ with a patched kernel.

This patchset adds the static/fallback labeling feature to NetLabel that has been requested on the SELinux mailing list more and more recently. This new bit of functionality also matches what can be found on similar trusted/labeled
OSs such as Trusted Solaris, HP-UX CMW, etc. This patchset it not yet ready for "upstreaming" so please do not pull this into any tree bound for the mainline kernel; I still need to do more review and testing of the code. However, I know there are several of you on this list that have been anxiously
awaiting this patchset so I thought I would make an early release so you could
get a peek and test it out. I won't be able to work on this patchset much, if
at all, between August 10th and the 20th so don't expect an update from me until the end of August.

The basic idea is that currently there is no method for providing an external label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO or labeled IPsec is not in use. This patch adds a mechanism for providing a static fallback label, specified per interface/network, which is used when a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

Quoted 6 lines · --- Paul Moore

The basic idea is that currently there is no method for providing an external label to fallback on if a labeled networking mechanism such as NetLabel/CIPSO or labeled IPsec is not in use. This patch adds a mechanism for providing a static fallback label, specified per interface/network, which is used when a NetLabel recognized labeling protocol (at this point CIPSO) is not in use.

I'm all in favor of the facility. I do however object to the use of a secid as the mechanism for storing the default label. As I've mentioned elsewhere, secid's are SELinux specific and add unnecessary overhead to schemes that don't use them natively. I understand and appreciate that SELinux is upstream, etc, etc. I understand that a scheme that does not use secid's is less convenient for SELinux. Please?