Log in

No account? Create an account

Layered Network Interfaces

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.


counter create hit
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: 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
    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.
counter create hit

LinuxCon NetLabel Presentation

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
counter create hit
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 ;)
counter create hit
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 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 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.
counter create hit
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.
counter create hit

Transitioning to Secmark

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

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
        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
# iptables -t mangle -A INPUT -p tcp --src --dport 22 -j SECMARK --selctx system_u:object_r:foo_ssh_packet_t:s0
# iptables -t mangle -L
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

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.
counter create hit

Email Difficulties Part Two

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.
counter create hit

Email Difficulties

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.
counter create hit

Labeled Networking in Linux 2.6.29

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


counter create hit


Paul Moore

Latest Month

August 2015


RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow