The labeled networking changes in 2.6.30 are fairly significant but not because of new features or functionality. The changes to 2.6.30 are largely fixes for bugs discussed previously as well as some minor improvements to Smack's internal labeled networking code. From a labeled networking user's point of view 2.6.30 doesn't do anything new, but it does everything it already does much better.

It is also worth noting that the TCP labeled networking bug fixes in 2.6.30 have been included in the 2.6.29.4 stable kernel release. I strongly encourage all of you running 2.6.28 or 2.6.29 kernels who aren't comfortable jumping to the 2.6.30 kernel to move your system to a 2.6.29.4 kernel as soon as possible.

UPDATE: I forgot to mention that the older "compat_net" network access controls have finally been removed in the 2.6.30 release. For those of you who may still be relying on the "compat_net" behavior, I've written a short guide on how to transition to the new Secmark based controls. If you run into any problems go ahead and drop a note in the comments.

The week of September 20th is going to be a busy one with both LinuxCon and the Linux Plumbers Conference co-located in Portland, Oregon. However, having both conferences in the same place on the same week should make it much easier for people to justify the travel. If you are planning on attending one or both of the conferences you should know that each conference has a dedicated security track or mini-summit which you probably want to attend (and submit a proposal too!).

On the day before LinuxCon starts, we will be holding this year's SELinux Developer's Summit. The SELinux Developer Summit is always a great opportunity to meet several of the SELinux developer's in person and discuss anything and everything SELinux. To get a better idea of what to expect you can check out the main page and talks from last year. For those of you interested in presenting a topic this year, the Call for Proposals is open until July 1st, so get your abstract in soon.

During the Linux Plumbers Conference there will be a dedicated security track for anything related to Linux security. The security track is new this year and promises to have some interesting talks, if you would like to add to that list James Morris put together a nice post with all the information you need; just beware the deadline for new proposals is June 15th.

Back in the 2.6.18 timeframe James Morris developed a replacement for the now-named "compat_net" SELinux access controls which filtered packets based on network attributes, the replacement was called Secmark. Secmark was introduced to fix two major issues with the aging compat_net access controls; the first problem being that they were not as flexible as iptables/netfilter rules and the second, very related problem, was that the compat_net controls were slow and likely would always be slow due to fundamental design issues. The solution to both these problems was to leverage the existing iptables/netfilter mechanism to label packets and replace the crude packet matching mechanisms of the compat_net design. As of 2.6.29 release the compat_net functionality is deprecated and patches completely removing it from the kernel have been merged into the 2.6.30 release candidates.

Secmark works by using iptables/netfilter to assign a label, or "security mark" aka Secmark, to specific packets which are later used by SELinux when the per-packet access controls are applied. This approach allows administrators to match packets based not only on the existing compat_net attributes such as port and host, but also any network attribute supported by iptables/netfilter, including stateful connection matching. The article by James Morris (linked above) is an excellent introduction to Secmark and for those of you looking to get the most out of the new functionality I encourage you to head over there first. What I hope to do here is not duplicate James' article, but rather provide a quick guide on how to duplicate basic compat_net functionality using the new Secmark controls.

Before we start it is important to first identify if the system you are using has Secmark enabled, you can do this by looking at the value in "/selinux/compat_net". If the file does not exist on your system and you have SELinux enabled then you are either using a very old kernel which does not support Secmark, or a new kernel (2.6.30 or greater) that only supports Secmark. However, for those systems that do have the file, if the contents are "0" then Secmark is enabled, otherwise you are still using the older compat_net controls. If you want to enable Secmark you can do so by writing a "0" to the file but you may first want to ensure that your SELinux policy and iptables/netfilter toolchain are up to date and provides Secmark support.

# cat /selinux/compat_net
0

The first step in using Secmark is to define a new SELinux label for the network traffic we are labeling and write the corresponding SELinux policy to handle the newly labeled traffic. This highlights the major difference between compat_net and Secmark: with the compat_net controls you assign labels to ports and hosts, but with Secmark you label the packets themselves. The second step is to determine which network attributes you want to match on when you are labeling packets. Both compat_net and Secmark can match on any combination of port and host so you should be able to transition all of your existing compat_net rules to Secmark; the only difference here is that with compat_net each port and host entry received its own label but with Secmark each combination of port and host receives a label. In the example below, we are going to configure Secmark to label SSH packets from host foo.lan with the label "foo_ssh_packet_t" and allow it to connect to the SSH daemon running on our local system with label "sshd_t". Careful observers will note that I currently have the MLS policy installed but the same procedure will work equally well with the default targeted policy.

Since we using a custom SELinux label the first thing we need to do is write a SELinux policy module to define the new type and the policy allowing this type to be received by the SSH daemon over the network. The policy we are using is shown below:

# policy header
policy_module(secmark_example,0.1.0)
gen_require(`
        type sshd_t;
')

# our new secmark packet type
type foo_ssh_packet_t;

# allow sshd_t to receive our new packet type
allow sshd_t foo_ssh_packet_t:packet recv;

We can quickly compile and install our new policy module with the following commands:

# cp /usr/share/selinux/devel/Makefile .
# make                                  
Compiling mls secmark_example module                      
/usr/bin/checkmodule:  loading policy configuration from tmp/secmark_example.tmp
/usr/bin/checkmodule:  policy configuration loaded                              
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/secmark_example.mod                                                                    
Creating mls secmark_example.pp policy package                                  
rm tmp/secmark_example.mod tmp/secmark_example.mod.fc                           
# ls                                                          
Makefile            secmark_example.if  secmark_example.te                      
secmark_example.fc  secmark_example.pp  tmp                                     
# semodule -i secmark_example.pp
# semodule -l | grep secmark_example
secmark_example 0.1.0

The next and final step is to setup the iptables/netfilter Secmark rules to label the packets correctly:

# host foo.lan
foo.lan has address 192.168.0.16
# iptables -t mangle -A INPUT -p tcp --src 192.168.0.16 --dport 22 -j SECMARK --selctx system_u:object_r:foo_ssh_packet_t:s0
# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
SECMARK    tcp  --  foo.lan              anywhere            tcp dpt:ssh SECMARK selctx system_u:object_r:foo_ssh_packet_t:s0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

At this point we are finished, packets coming from foo.lan and destined for port TCP/22 on our system will be labeled as "foo_ssh_packet_t" with SELinux providing assurance that only "sshd_t" can read "foo_ssh_packet_t" packets. You can verify this quite easily be removing the allow rule from the custom SELinux policy and watching SSH traffic from foo.lan stop, you will also see new SELinux AVC denial messages with the "foo_ssh_packet_t" type.

One final note, remember that with modern Linux Kernels there are two types of SELinux security labels assigned to a packet, the Secmark labels described here and the peer labels described previously. These two types of packet labels operate differently and subject to their own, independent set of SELinux access controls. The Secmark packet labels are used to represent the network attributes of a packet such as IP addresses and ports, while the peer packet labels are used to represent the security attributes of the sender such as the SELinux label of the process which generated the network packet.

UPDATE: Laszlo Beres has been kind enough to provide a Hungarian translation.

It appears that my email account has hit internal routing issues yet again which means I haven't been receiving email since sometime on Friday evening. The truly unfortunate part of this (other than the fact that it happened _again_) is that with this being the weekend it is unlikely that this will get resolved until sometime next week. Sigh.

For the near future if you need to reach me you can do so at pmoore at ldl dot fc dot hp dot com.

UPDATE: this should be resolved now, you can reach me either at either address in the future.

There was a problem with my email account last Friday, May 1st, which caused all mail sent to my account to bounce leading to lost mail and automatic forced removal from many mailing lists. Everything should be back to normal now, including my mailing list subscriptions, but if you sent me mail during the past few days and you haven't heard back from me yet I would recommend resending the original mail.

Sorry about that.

While the 2.6.28 release of the Linux Kernel brought a lot changes to the labeled networking code the 2.6.29 release is much smaller with only a handful of fixes and a partially implemented new feature, single label host support for Smack. The new single label host support for Smack allows users to specify a single, static security label for a network or single host which is used when network labeling protocols are not supported or can not be used. It essentially brings NetLabel's fallback label functionality to Smack for the first time. Unfortunately, there were some problems in the implementation that were not spotted in time to be resolved for the 2.6.29 release which means that TCP connections may not behave as you expect when using the new single label functionality in Smack. UDP should work as expected as well as TCP connections made when the single label support is not configured.

Hopefully we will have a fix in place before the 2.6.30 merge window closes, if so I'll work to get the fix backported to the -stable trees so that the Smack single label support in Linux 2.6.29 will work correctly. Once that it settled I'll post a quick How-To here so you can try it yourself (I expect this to be a very popular addition to Smack).

One of the new features added in Linux 2.6.28 was the ability to send full SELinux labels/contexts over local connections using NetLabel. Unfortunately a bug was recently discovered in how NetLabel applies on-the-wire security labels to responses of incoming TCP connections which significantly affects the native labeling added in 2.6.28. The bug has likely been present since 2.6.25 (I haven't verified this yet) and only affects the on-the-wire label of packets sent by a TCP application which accepts incoming connections. Because of this I'm going to refrain from posting the How-To on how to make use of the new native labeling capabilities until the bug is fixed.

Patches are currently under development which should solve this issue and I expect the fix to be included in the 2.6.30 release of the Linux Kernel. Once the issue has been resolved in the 2.6.30 release candidates I will work on developing a set of patches to address the problems in the stable kernel trees (2.6.27 and 2.6.28 at the time of this writing) but that will likely lag the mainline fix by a week or two due to the re-engineering needed for the stable trees.

Sorry about this; I hope to have it fixed soon, in the meantime I ask for your patience.

One of the biggest differences between NetLabel and the labeled networking mechanisms of existing Trusted OSs is how outbound traffic is selected for labeling. Ever since NetLabel was first introduced in kernel 2.6.19 the on-the-wire outbound labeling protocol was determined by the label of the sending application's socket. Despite the departure from legacy approaches, this was a concious choice designed to make the implementation smaller and less invasive in an attempt to gain acceptance into the mainstream Linux Kernel. While ultimately this approach proved to be successful, NetLabel was accepted, it did have its drawbacks. The most significant was that all traffic from a single socket, or application if it was not label aware, was limited to the same on-the-wire label; if you think about this for a minute you quickly realize how limiting this could become. Thankfully with kernel 2.6.28 this is no longer the case.

In kernel 2.6.28 we introduced the concept of address selectors to NetLabel. NetLabel address selectors allow administrators to specify the on-the-wire label format based on both the sending application and the destination address. This is a huge usability boost as administrators are no longer forced to use the same on-the-wire label format for a single application, making deployment much easier. To help make things a bit more concrete, let's examine the following configuration:

# netlabelctl cipsov4 add pass doi:16 tags:1
# netlabelctl map add domain:apache_t protocol:cipsov4,16
# netlabelctl -p map list
Configured NetLabel domain mappings (2)
 domain: "apache_t"
   protocol: CIPSOv4, DOI = 16
 domain: DEFAULT
   protocol: UNLABELED

Before kernel 2.6.28 this is how you used to enabled NetLabel based labeling for an application. In this particular example we are configuring Apache (apache_t) to label outbound traffic with a CIPSO label using CIPSO DOI 16. This configuration would apply CIPSO labeling to all traffic regardless of destination; DNS queries, Windows clients, other Linux hosts, everything would receive CIPSO labeled traffic. However, starting with Linux Kernel 2.6.28 and NetLabel Tools 0.19 there are some new parameters to the netlabelctl map command:

# netlabelctl cipsov4 add pass doi:17 tags:5
# netlabelctl map add domain:firefox_t address:0.0.0.0/0 protocol:unlbl
# netlabelctl map add domain:firefox_t address:10.0.0.0/8 protocol:cipsov4,17
# netlabelctl map add domain:firefox_t address:192.168.4.5 protocol:cipsov4,16
# netlabelctl -p map list
Configured NetLabel domain mappings (3)
 domain: "apache_t"
   protocol: CIPSOv4, DOI = 16
 domain: "firefox_t"
   address: 192.168.4.5/32
    protocol: CIPSOv4, DOI = 16
   address: 10.0.0.0/8
    protocol: CIPSOv4, DOI = 17
   address: 0.0.0.0/0
    protocol: UNLABELED
 domain: DEFAULT
   protocol: UNLABELED

Using the new address option to the netlabelctl map command allows us to add a destination address selector to the NetLabel LSM domain mapping configuration. In this particular example we've configured Firefox (firefox_t) to send CIPSO DOI 16 labeled packets to host 192.168.4.5 and CIPSO DOI 17 labeled packets to the entire 10.0.0.0/8 network while everyone else, specified by 0.0.0.0/0, is sent unlabeled packets. You will also notice that the new address selectors can coexist with the existing configuration, e.g. our Apache configuration is untouched, but you can only add address selectors to domains which make use of address selectors, e.g. you can't add address selectors to the above Apache configuration. If you want to add address selectors to an existing domain configuration you first need to delete it and recreate it using address selectors as show below:

# netlabelctl map add domain:apache_t address:192.168.3.5 protocol:unlbl
netlabelctl: error, invalid argument or parameter
# netlabelctl map del domain:apache_t
# netlabelctl map add domain:apache_t address:0.0.0.0/0 protocol:cipsov4,16
# netlabelctl map add domain:apache_t address:192.168.3.5 protocol:unlbl
# netlabelctl -p map list
Configured NetLabel domain mappings (3)
 domain: "apache_t"
   address: 192.168.3.5/32
    protocol: UNLABELED
   address: 0.0.0.0/0
    protocol: CIPSOv4, DOI = 16
 domain: "firefox_t"
   address: 192.168.4.5/32
    protocol: CIPSOv4, DOI = 16
   address: 10.0.0.0/8
    protocol: CIPSOv4, DOI = 17
   address: 0.0.0.0/0
    protocol: UNLABELED
 domain: DEFAULT
   protocol: UNLABELED

That covers the new NetLabel address selectors in kernel 2.6.28, however there are a few things you should make note of before you start playing with this new feature. The most important is that the address selectors require NetLabel Tools version 0.19 or higher, information on where to get version 0.19 can be found here. The next thing to keep in mind is that when you are configuring NetLabel using address selectors you will almost always want to have a 0.0.0.0/0 address configured as a "catch all" address, otherwise you could run into problems if you try to send traffic to an address not explicitly configured. Other than that, have fun and let me know if you have any problems in the comments.

Yesterday I announced a new release of the NetLabel Tools package and promised a post detailing the new labeled networking features in Linux 2.6.28. James Morris saw that and called me out in his nice summary of the security relevant changes in the 2.6.28 release, so I guess I had better make good on my promise.

The 2.6.28 release of the Linux Kernel is the biggest labeled networking update since 2.6.25. There are only two major new features in this kernel release but they are likely to be some of the most welcomed changes since NetLabel was first introduced in Linux 2.6.19. The first feature added to the kernel was the ability to specify the NetLabel labeling configuration not only by LSM domain but also by destination address. The second feature added was a new CIPSO tag type which allows native LSM/SELinux security labels to be carried over local connections (yes, this means full SELinux context support, not just the MLS attributes).

I'll go into more detail in later posts, but for those of you eager to get started you'll need to grab Linux Kernel 2.6.28 and NetLabel Tools version 0.19 (or later). If you check out the netlabelctl man page you will find information on using the new features and examples for each; if you have any questions drop a comment below.

A new version of the Netlabel Tools package has been released. Version 0.19 includes support for the new features found in Linux Kernel 2.6.28 (more on that later) as well as a number of improvements to the code which aren't always user-visible. Hit the links in this post to get the latest bits.

NetLabel userspace download: netlabel_tools version 0.19
Fedora bugzilla entry: RH BZ #478903

I've already talked about Fallback Labels and Network Peer Controls now I'm going to explain the last major labeled networking feature included in the 2.6.25 release of the Linux Kernel, the network ingress/egress controls. One of the longstanding problems with the SELinux network access controls was that they lacked any ability to control packets at the network interface level, limiting our ability to provide access control based on the physical network and making it impossible to provide access control for forwarded packets. The network ingress/egress controls were designed to solve these problems by placing SELinux network access controls at the network interface level.

The new ingress/egress controls are fairly simple: each packet entering the system must pass an ingress access control and each packet leaving the system must pass an egress access control. Forwarded packets must also pass an additional forwarding access control, but I'm going to leave that for another time and focus on the ingress/egress cases. In both the ingress and egress access controls the network packet is subjected to network interface and network address checks. In order to allow incoming network traffic to enter the system you need the following two allow rules (where network_if_t is the network interface's label, network_addr_t is the remote host's network address label and peer_t is the traffic's peer label):

allow peer_t network_if_t:netif ingress;
allow peer_t network_addr_t:node recvfrom;

Network traffic leaving the system requires similar allow rules:

allow peer_t network_if_t:netif egress;
allow peer_t network_addr_t:node sendto;

As a reminder the peer labels, peer_t in the above examples, are derived from the original sender's security label. In the case of incoming network traffic the peer label is taken from the network labeling protocol, if available, and in the case of outgoing network traffic the peer label is taken from the application/socket which generated the traffic. The network interface and address labels are defined as part of the SELinux policy and can be modified on-the-fly using the semanage tool.

Moving on to a more concrete example, imagine a web server running Apache with the eth0 network interface labeled as "wwwsrv_if_t", no explicitly labeled network addresses (which means addresses will be represented by the default address label, "node_t") and a "private_net_t" fallback label defined for addresses that match 192.168.0.0/16. If we want to allow network traffic from 192.168.0.0/16 over the eth0 interface into the system and allow responses back from Apache we need to write the following allow rules:

allow private_net_t wwwsrv_if_t:netif ingress;
allow private_net_t node_t:node recvfrom;
allow apache_t wwwsrv_if_t:netif egress;
allow apache_t node_t:node sendto;

Like the new network peer controls, the ingress/egress controls are currently not enabled, protected by the same policy capability flag which protect the peer controls, "network_peer_controls". I am currently testing a small patch which should solve the remaining policy issues and allow us to finally enable this new functionality. In the meantime if you want to try it yourself you need to uncomment the "policycap network_peer_controls;" line in the policy_capabilities file found in the SELinux Reference Policy sources and rebuild the policy. Good luck, and if you hit any snags don't hesitate to drop a comment below and I'll help you sort it out.

In addition to Fallback Labels another new feature added to the 2.6.25 release of the Linux Kernel was the consolidation of the access control permissions for the different peer labeling mechanisms supported by SELinux. This consolidation has several benefits including better handling of traffic with multiple peer labels (all of the labels must be the same), elimination of confusing and duplicated per-packet access checks, and the creation of a new object class which abstracts away the underlying labeling protocol making policy development easier and more consistent.

Prior to the new network peer controls each peer labeling mechanism, NetLabel and Labeled IPsec, had separate access controls. In the early days of NetLabel this made sense as it allowed NetLabel development to proceed without impacting the existing Labeled IPsec mechanism, however, as time has progressed the additional access controls have proven problematic both from a code and policy management point of view. Those familiar with the old system know that in order to receive network traffic labeled with either NetLabel or Labeled IPsec you needed the following two allow rules (where socket_t is the receiving socket's label and peer_t is the packet's peer label):

allow socket_t peer_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
allow socket_t peer_t:association recvfrom;

The first allow rule allows NetLabel traffic whereas the second allow rule allows Labeled IPsec traffic. This duplication of access checks led to some interesting situations when only one peer labeling mechanism was in use, which happens to be the common case. The problem is that if you were using Labeled IPsec to browse the web you would need the following permissions:

allow firefox_t unlabeled_t:tcp_socket recvfrom;
allow firefox_t apache_t:association recvfrom;

You notice how the first access check requires access to unlabeled_t? This makes sense as NetLabel is not in use for this particular connection and is not able to generate a peer label, but it can be very confusing for users, policy writers and pretty much everyone else. The same problem happens when NetLabel is used and Labeled IPsec is not.

The solution to this was to consolidate the two access controls into a single access control. Doing so would not only simplify SELinux policy but also allow us to cleanup and consolidate much of the related SELinux kernel code. The new network peer controls work by deriving a single peer label for a network packet and then applying a single access check. In the rare case that multiple peer labels are present on a packet they must be equivalent for the packet to be considered valid; invalid packets are dropped. The resulting single access check looks like this:

allow socket_t peer_t:peer recv;

The new access check behaves exactly like the previous checks in that socket_t is the security label of the receiving socket and peer_t is the packet's peer label (unlabeled_t when no peer labeling is in use). The difference being that it is only evaluated once per packet and is protocol agnostic; a big improvement on both counts.

While I believe most would agree that the new network peer controls are a welcome change, the fact remains that they are a change and a mechanism must exist to allow a smooth transition between the old and new controls. To solve this problem the concept of "policy capabilities" (yes, I know it is a poor name) was introduced which allows policy writers to selectively enable or disable kernel features. As of right now I am not aware of any SELinux policy, including the Reference Policy which enables the new controls. You can check your own system by running the following command (0 means the legacy controls are in use, 1 means the new controls are in use):

# cat /selinux/policy_capabilities/network_peer_controls

Later on I'll explain how to enable the new network peer controls, but first I need to describe the new network ingress/egress access controls which are also enabled by the "network_peer_controls" policy capability. I don't want anyone having a nasty surprise :) More on the ingress/egress controls in the next post.

One of the new features added to the 2.6.25 release of the Linux Kernel was the ability to specify fallback peer labels using NetLabel. This made it possible for system administrators to specify a peer label to be used in the absence of a peer labeling protocol such as CIPSO or Labeled IPsec. In this post I'll try to provide a quick introduction on how to configure NetLabel to provide fallback peer labels.

The first step is to make sure you have all the right kernel and userspace bits in place. Any standard Linux distribution kernel 2.6.25 or greater that has NetLabel support should work. In addition to the kernel you will need to make sure the userspace utility, netlabelctl, supports the new configuration options; this requires netlabel_tools version 0.18 or greater. Once you have verified that you have the right versions installed and running, you can verify everything by running the following commands.

# netlabelctl -p mgmt version
NetLabel protocol version : 2
# netlabelctl -h
NetLabel Control Utility, version 0.18 (libnetlabel 0.18)
 Usage: netlabelctl [<flags>] <module> [<commands>]

 Flags:
   -h        : help/usage message
   -p        : make the output pretty
   -t <secs> : timeout
   -v        : verbose mode

 Modules and Commands:
  mgmt : NetLabel management
    version
    protocols
  map : Domain/Protocol mapping
    add default|domain:<domain> protocol:<protocol>[,<extra>]
    del default|domain:<domain>
    list
  unlbl : Unlabeled packet handling
    accept on|off
    add default|interface:<DEV> address:<ADDR>[/<MASK>]
                                label:<LABEL>
    del default|interface:<DEV> address:<ADDR>[/<MASK>]
    list
  cipsov4 : CIPSO/IPv4 packet handling
    add trans doi:<DOI> tags:<T1>,<Tn>
            levels:<LL1>=<RL1>,<LLn>=<RLn>
            categories:<LC1>=<RC1>,<LCn>=<RCn>
    add pass doi:<DOI> tags:<T1>,<Tn>
    del doi:<DOI>
    list [doi:<DOI>]

The first command checks to see that the kernel speaks version 2 of the NetLabel control protocol which means that it understands the new fallback peer label configuration options. The second command verifies that you have netlabelctl version 0.18 installed and that it supports the fallback configuration commands that we will be using. If everything looks okay it is time to move on to the next step, building a test tool that we can use to verify the configuration. Obviously this isn't a strict requirement for configuring the fallback label mechanism but it is a nice way to verify that your configuration is correct. The test tool I will be using here is a simple little test program I wrote some time ago to test basic peer label functionality for IPv4 TCP sockets, I call it getpeercon_server. Once you have downloaded the C source file you will need to compile it with the following command, if you are on a Fedora system make sure you have the libselinux-devel package installed.

# gcc -o getpeercon_server getpeercon_server.c -lselinux
# ./getpeercon_server
usage: ./getpeercon_server <port>

As you can see the tool is very simple and takes a single argument, the TCP port to bind to a listen for connections. If you start the server on port 5000 and connect to it with telnet, netcat, or some other simple TCP application you should see something similar to what is shown below.

# ./getpeercon_server 5000
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(127.0.0.1,NO_CONTEXT)
Hello NetLabel Fans!
-> connection closed
-> waiting ...

In the example above we can see that a client connected from localhost, 127.0.0.1, and there was no peer label information provided with the connection, NO_CONTEXT. Now lets configure a fallback peer label for localhost and try it again. Adding a fallback label is relatively simple and can be done with a single command. However, the example below executes two commands. The first command adds a fallback label, "system_u:object_r:netlabel_peer_t:s0", to all traffic coming over the loopback interface, "lo", from localhost, 127.0.0.1. The second command displays all of configured fallback labels; not a necessary step but helpful to ensure that you configured everything correctly.

# netlabelctl unlbl add interface:lo address:127.0.0.1 \
                        label:system_u:object_r:netlabel_peer_t:s0
# netlabelctl -p unlbl list
Accept unlabeled packets : on
Configured NetLabel address mappings (1)
 interface: lo
   address: 127.0.0.1/32
    label: "system_u:object_r:netlabel_peer_t:s0"

Now, lets try our simple connection test again with our newly established fallback label configuration.

# ./getpeercon_server 5000
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(127.0.0.1,system_u:object_r:netlabel_peer_t:s0)
Fallback Labels Are Really Cool!
-> connection closed
-> waiting ...

If you look at the output you will notice almost everything is the same except for one important thing, instead of NO_CONTEXT the test tool is displaying the fallback label we just configured. The kernel treats the NetLabel fallback label just the same as a normal peer label taken from a CIPSO tag or Labeled IPsec Security Association. This means that not only is the fallback label passed to applications that request it, it is also used when enforcing the LSM's network security policy; in this case SELinux. However, it is important to remember that the fallback labels are overridden by peer labeling protocols. As a result, if both fallback peer label information and Labeled IPsec peer label information is available then the kernel will use the Labeled IPsec peer label information and ignore the fallback peer labels. Fallback peer labels can be configured based on the network interface, network address, and netmask or just network address and netmask when the default network interface is chosen.

Before you start making use of the NetLabel fallback labels, there are a few things you should take into consideration. First, while the fallback functionality was included in Linux Kernel 2.6.25 there was a small bug which prevented some IPv6 fallback labels from being displayed correctly using the "netlabelctl -p unlbl list" command; this has been fixed in kernel 2.6.26. Second, Fedora has not yet adopted version 0.18 of netlabel_tools which means that you will need to download and build netlabelctl separately to take advantage of the new fallback functionality. A Red Hat bugzilla entry has been filed to get the latest netlabel_tools package included in Fedora.

Test tool download: getpeercon_server
NetLabel userspace download: netlabel_tools version 0.18
Fedora bugzilla entry: RH BZ #439833

Thanks to James Morris for pointing out that the Linux Foundation Japan videos are now online. I've put a copy at the link below. All I ask is that you remember I had been in Japan less than a day when this was filmed and was still dealing with a 13 hour time difference :)

Video download: Introduction to Labeled Networking on Linux

I'm at OLS right now, but the day before OLS started we held this year's SELinux Developer's Summit as part of OLS's mini-summit program. This year's summit was a bit of a departure from previous years in that the summit consisted of several short presentations and was open to everyone. Personally, I thought it went very well, with lots of good work-in-progress presentations, my favorite kind, and plenty of discussion. My own contribution, an update on the state of SELinux Labeled Networking, can be found below. James Morris has posted all of the slides on the schedule page, so you can check out what was discussed if you weren't able to make it to Ottawa this year.

Hopefully we will be able to continue having regular SELinux Developer Summits in the future that are similar to the one this year. There is even some talk about extending future summits to include both a presentation day and a hack-fast day. I can't remember who proposed the hack-fest day, but I like it. Especially if we hold it in Hawaii :)

Presentation download: State of SELinux Labeled Networking

When I think about all of the items on my Linux Labeled Networking todo list one of the items that stands out the most is the lack of good, useful documentation. Oh sure, there is some documentation available, for instance Joshua Brindle's blog post about Labeled IPsec on SELinux, but most of it is quickly becoming dated and no longer a good fit with current kernels and tools. A big part of the problem is the amount of ongoing development which makes it difficult to spend much time writing documentation. I've managed to convince myself that development of user requested features is more important than documentation, but I suppose that does little to help people who are trying to use and configure the existing labeled networking features.

While I still think development is more important, we still have a lot of usability functionality to implement, I am going to try and do a better job of documenting the Linux Labeled Networking features. Part of that effort is the creation of this blog where I plan to talk about Linux Labeled Networking development and related topics. To kick things off I've posted slides from a presentation I gave earlier this week at the Linux Foundation's Japan Symposium, the presentation is designed to be a quick introduction to labeled networking on Linux including overviews of Secmark, NetLabel, and Labeled IPsec.

Presentation download: Introduction to Labeled Networking on Linux