Playing with Packets

Wrapping Up The 2011 Linux Security Summit

2011-09-09T06:55:34Z

We just closed the doors on the 2011 Linux Security Summit a few hours ago and I wanted to jot down a few notes while everything was still fresh in my mind. Once again, a big thanks to all of our presenters, James Morris and the rest of the organizing committee; my personal opinion is that the summit was a success this year and I look forward to doing this again in 2012.

Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.

http://security.wiki.kernel.org/index.php/LinuxSecuritySummit2011

Smack is Alive and Well, Casey Schaufler

This presentation started with a brief introduction to Smack and then moved on to presenting the recent users, motivations and focus. While Smack has been incorporated into at least one general purpose Linux Distribution, Ubuntu, over the past year or two Smack has grown increasingly focused on small and embedded devices. Functionality wise, Smack has gained several new additions including process labels and transmutable directories. Process labels allow an executable file to be started with a label specified in the file's xattrs and not the parent process's attributes. Transmutable directories allow two differently labeled processes to write into each other's directories without requiring full write access to the other label; this should make it much easier to share files and data between labels. Beyond the new functionality, performance improvements, increased Linux Test Project coverage and improved consistency between AF_UNIX and AF_INET sockets have seen their way, or will soon see their way into Smack.

MeeGo platform security, including Smack userspace: http://meego.gitorious.org/meego-platform-security

The Case for SE Android, Stephen Smalley

This presentation discussed a recent effort to prototype a SELinux implementation for Android. While SELinux is well known in desktop and server Linux environments, it is still rare in mobile and embedded systems due to concerns around resource usage and differences in both the kernels and userspace. This talk explained the basic Linux/Android differences and what was needed to enable SELinux on the Android platform. Resource issues around policy size were addressed through a greatly simplified SELinux policy which avoided per-application policy and relied on a relatively simple rule set. Finally, the effectiveness of the prototype was evaluated by examining a recent Android vulnerability with a known exploit and determining the effectiveness of the SELinux Android port in preventing the exploit. In the end, this remains a prototype at present, designed to investigate Android's security capabilities, but it shows quite a bit of promise and has a lot to offer beyond the current Android security functionality.

Overview of the Linux Integrity Architecture, David Safford and Mimi Zohar

The Linux Integrity Architecture project has seen a lot of activity over the past few years and the presentation started off with an overview of project, including a status update on where each piece of functionality stood with respect to upstream and established distributions. The good news is that almost all of the IMA project is either currently upstream or patches have been submitted and are being discussed on the related mailing lists. One of the presentation highlights was a demo tying together the IMA principals and virtualization to demonstrate a "Trusted Cloud". While there is work to be done, the IMA project has made great strides and already offers some impressive functionality.

IMA project website: http://linux-ima.sf.net

Digital Signature Support for IMA/EVM, Dmitry Kasatkin and Casey Schaufler

This presentation addressed a problem common to system and device manufacturers who install a single "golden image" on each system they ship: how do you reconcile the business need of a single install image with a TPM based EVM HMAC which uses a per-device key stored in the TPM? One potential answer is to expand on the EVM mechanism to support public key digital signatures in addition to the TPM based HMAC. When the devices are initially installed, a public key certificate is installed into the Linux Kernel keyring via an initrd with the filesystem using digital signatures for the EVM xattr in place of the traditional HMAC. As the files are accessed, the EVM digital signature is verified, and if correct, it is replaced by a TPM generated HMAC. If the EVM digital signature verification fails, access is denied in the same way as if the EVM HMAC verification had failed.

Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM, Peter Kruus

This presentation covered some work being done to better secure Fedora 15 guests running on VMWare ESXi while the guests were both running and offline. All systems are vulnerable to offline attacks, but in the case of virtual systems, offline vulnerabilities can sometimes be much easier to exploit due to the availability of the host system and guest storage volumes. In order to help mitigate this problem, the presenter leveraged the existing IMA/EVM support in Fedora 15 to verify the integrity of critical system files, but unfortunately due to missing vTPM support in VMWare ESXi the presenter was unable to leverage TPM based HMACs in the EVM attributes. The solution was to use a passphrase protected key which was loaded at boot through a combination of the system's initrd and dracut. While this solution does provide an increased level of protection against attack, for this approach to be truly successful, full vTPM support is needed in the hypervisor to allow the guest to utilize the TPM. While vTPM patches have been submitted for QEMU/KVM, the state of the vTPM in VMWare ESXi is unknown.

Integrity-checked Block Devices with Device Mapper, Will Drewry and Mandeep Baines

This presentation dealt with an enhancement to the Linux Kernel Device Mapper to perform block level integrity verification. This solution was designed primarily for the Linux based Chromium OS running on modest netbook class hardware where boot performance was a significant requirement. Helping to simplify the solution was the fact that the system is very well defined and operates in a read-only mode such that the integrity verification mechanism does not need to worry about online updates to the storage volume. The solution, dm-verity, uses a slightly modified hash tree, with the root hash specified on the kernel command line to quickly verify the integrity of the entire block device. Optimization is ongoing, but already the developers are able to boot a ~800MB Chromium OS root partition in ~1.2s on an Atom CPU using a SSD storage volume. While this integrity verification solution may not lend itself quite as well to general purpose systems as the TPM/IMA based solutions, it presents a novel solution that helps solve Chromium OS's needs in a a high performance, low cost manner.

Kernel Hardening Roundtable, Kees Cook and Will Drewry

This roundtable started with a discussion on the different kernel interfaces where the kernel is exposed to user input, malicious or otherwise. From here the focus shifted to how the existing security mechanisms, such as DAC, LSM and capabilities, impact the kernel's exposed interfaces - for better or worse. At this point it was clear, if it wasn't already, that the Linux Kernel remains far too exposed to malicious users/applications and some additional hardening techniques are needed.

While many hardening ideas were discussed, the two main points of discussion revolved around system call filtering/reduction and the hardening techniques found in grsecurity. With respect to system call filtering, work has been ongoing this year to expand the mainline seccomp functionality to be more flexible and useful for a wider range of applications. Plenty of discussion has already occurred on the mailing lists and more is expected as the enhanced seccomp developer has promised a new round of patches soon. Similarly, work has recently been ongoing to decompose the rejected grsecurity patch and repackage it in a series of patches which will hopefully be acceptable to the upstream kernel maintainers.

Sandbox powered by the current mainline seccomp: http://code.google.com/p/seccompsandbox
Ubuntu Linux Kernel hardening tasks: http://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
Linux Kernel hardening mailing lists: http://www.openwall.com/lists (see the kernel-hardening list)

LSM Architecture Roundtable, Kees Cook and Casey Schaufler

This roundtable dealt primarily with the issues related to multiple LSMs, from APIs and determining which LSM was enabled in the kernel to architectural issues blocking multiple concurrent LSMs. With respect to determining the active LSM and LSM APIs, the discussion was largely a group brainstorming session with developers discussing the pros and cons of various solutions; while most agreed the a general LSM userspace API was more problem than it was worth, there was some general agreement on LSM conventions that should help unify some of the most basic LSM API functionality in the future.

This discussion around running multiple concurrent LSMs was much more focused, with patches being proposed as recently as February, although everyone did agree that the patches had serious limitations due to shortcomings with the LSM hooks/blobs in the kernel. In the end, several inherent blockers to concurrent LSM operation remained, but the "religious" arguments against the idea seemed to be less than in past years.

Twitter Too

2011-08-15T22:39:18Z

To add to the recent email updates, I thought I would mention that I'm now on twitter too at @paul_via_tweet. Not much there right now, but since all the "cool kids" are on the twitter these days, how could I resist?

New Email Address Part Two

2011-08-10T18:08:11Z

Hello again, last week I made a quick post to say that my @hp.com email address was going away; the reason for that, as many had guessed, was that I was leaving HP for a new employer. As of this past Monday, August 8th, 2011, I'm happy to say that I am now working for Red Hat. This should be good news for anyone interested in the Linux labeled networking bits and the assorted LSM network access controls as my new employer should allow me to spend more time maintaining and working on these things than I have over the past few years.

So, with a new job comes a new email address; you can continue to send me email at paul@paul-moore.com, but now you can also reach me at pmoore@redhat.com.

New Email Address

2011-08-01T21:16:45Z

Just a quick update to let everyone know that my @hp.com email address is going to stop working on Friday, August 5, 2011. If you need to get in touch with me please send me email at paul@paul-moore.com.

Layered Network Interfaces

2010-11-08T20:53:16Z

If you've ever configured a tagged VLAN on a Linux system you know that for each VLAN ID on the system there exists a matching network interface, this is a nice feature that helps ease the pain of managing multiple VLANs but it presents an interesting question for SELinux administrators: how do the interface level access controls work? Since the individual VLAN interfaces are "layered" on top of the underlying physical interface, do the SELinux access controls happen at the physical interface, the VLAN interfaces or both?

It turns out the answer is quite simple and applies regardless of how many layers of network interfaces you have configured; the SELinux interface level network access controls are applied to traffic as it pass through the top most interface layer. In the case of a system configured with multiple tagged VLANs, the access controls are applied at the VLAN interface layer. In the case of a system configured with multiple tagged VLANs running on top of a bonded interface running on top of a pair of physical interfaces, the access controls are applied at the VLAN interface layer. Regardless of the number of interface layers, the SELinux access controls are always applied to the top most interface layer.

Further, assigning SELinux security labels to these pseudo-interfaces is done the same way you would for a regular physical interface: using the semanage tool. Once you have the interfaces labeled, you can start defining your network access control policy just as if you were working with a physical interfaces.

Enabling the Network Ingress/Egress Controls

2010-01-22T22:35:42Z

There have been quite a few questions lately about how to enable the SELinux network ingress/egress controls on recent Fedora releases. This is good because it means people actually want to use this stuff, but it is also bad because it tells me that I haven't done a very good job explaining how to use them. Actually, looking back on this site I see that while I've written about the ingress/egress controls I haven't described how you would enable them on a modern Linux distribution. Ooops.

However, fear not faithful readers and confused administrators, for this is post shall explain, in four easy steps, how to enable the SELinux network ingress/egress controls. Without further ado, let's begin ...

The first step is to ensure you have the netlabel_tools package installed. This is necessary because the netlabel_tools package contains the netlabelctl application which we will be using to configure NetLabel in the final step. Using yum you should be able to install netlabel_tools with the following command:

# yum install netlabel_tools

After you have installed the netlabel_tools package the next step is to ensure you have a SELinux policy module loaded which defines at least two new types: one to be assigned to a network interface and another to be assigned to network traffic. To be honest, you'll probably want to create more than just those two types but that will be dependent on your particular configuration; for more information I suggest you look at my original post on the ingress/egress controls where I go into more detail on the policy aspect of these controls. Regardless of what you decide, for the example here I will be using "foo_netif_t" for the network interface type and "foo_peer_t" for the network traffic type.

With the SELinux policy module loaded and our new types defined, it is time to assign our new network interface type to an interface on the system. We use the semanage tool to manipulate the SELinux types assigned to network interfaces, in order to add a type to an interface, "eth2" in this example, we use the following command:

# semanage interface -a -t foo_netif_t eth2

We can verify that the interface is assigned the correct type with the following command:

# semanage interface -l
SELinux Interface              Context
eth2                           system_u:object_r:foo_netif_t:s0

Now that we have the network interface labeled the final step is to setup some form of peer labeling on the network. For many of you not using CIPSO or labeled IPsec, this means configuring NetLabel's static/fallback labels. In this example, we are going to configure all of the IPv4 and IPv6 traffic entering the system via "eth2" as having the "foo_peer_t" label; we do this with the following command:

# netlabelctl unlbl add interface:eth2 address:0.0.0.0/0 label:system_u:object_r:foo_peer_t:s0
# netlabelctl unlbl add interface:eth2 address:::/0 label:system_u:object_r:foo_peer_t:s0

We can verify the configuration with the following command:

# netlabelctl -p unlbl list
Accept unlabeled packets : on
Configured NetLabel address mappings (2)
 interface: eth2
   address: 0.0.0.0/0
    label: "system_u:object_r:foo_peer_t:s0"
   address: ::/0
    label: "system_u:object_r:foo_peer_t:s0"

At this point the SELinux network ingress/egress control should be up and running on your system. As a reminder, you'll want to be sure to have all the right allow rules for these new controls in your SELinux policy as simply adding the types without the allow rules could result in a total loss of network access; because of this I recommend you do this with SELinux in permissive mode until you are comfortable with how the system operates.

Good luck, and as usual, if you have any problems or questions feel free to leave a comment below.

LinuxCon NetLabel Presentation

2010-01-22T21:47:06Z

I'm more than a little late posting this, but below you'll find a copy of the NetLabel presentation I gave at this past year's LinuxCon. Sure, it is old news, but if you ever wanted to know what NetLabel does and why it exists in the first place this is still good stuff.

Presentation download: NetLabel: What, Why & Where

NetLabel Presentation and Tutorial at LinuxCon

2009-09-03T22:04:02Z

In a few weeks I'll be giving a presentation and tutorial on NetLabel at LinuxCon. Both as a speaker and as a member of the audience I've always felt that the best presentations/tutorials are the ones that cover what the audience is really interested in hearing. The only problem is that in most cases the presentation material needs to be generated before the presenter ever meets the audience. With that in mind, I'd like to reach out to all of you reading this entry and ask two simple questions:

* What would you like to see in a NetLabel presentation?
* What would you like to learn in a NetLabel tutorial?

Don't be shy now ;)

Labeled Networking in Linux 2.6.30 and 2.6.29.4

2009-06-11T18:35:31Z

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.

Call For Security Proposals - LinuxCon and The Linux Plumbers Conference 2009

2009-06-09T21:31:59Z

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.

Transitioning to Secmark

2009-05-21T22:10:26Z

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.

Email Difficulties Part Two

2009-05-09T16:07:37Z

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.

Email Difficulties

2009-05-04T20:13:05Z

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.

Labeled Networking in Linux 2.6.29

2009-03-25T15:26:59Z

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

Problems with NetLabel's Native SELinux Labeling in 2.6.28

2009-03-18T18:22:40Z

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.

NetLabel Address Selectors Explained

2009-02-13T22:50:59Z

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.

Labeled Networking in Linux 2.6.28

2009-01-06T22:25:15Z

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.

NetLabel Tools 0.19 Released

2009-01-05T22:19:36Z

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

Network Ingress/Egress Controls Explained

2008-12-05T23:37:42Z

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.

Network Peer Controls Explained

2008-10-06T22:00:45Z

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.

Fallback Label Configuration Example

2008-08-13T22:00:43Z

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

Linux Foundation Presentation Video

2008-08-04T23:07:27Z

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

SELinux Developer's Summit 2008

2008-07-24T23:26:17Z

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

The Importance of Documentation

2008-07-11T11:16:25Z

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