I gave a brief presentation on virtualization security at the Linux Plumbers Conference this year as well as a lightning talk on seccomp/libseccomp at the Linux Security Summit. The slides for both presentations are available below.
Virtualization Security Discussion: http://www.paul-moore.com/files/lj/virt_
Syscall Filtering Made (sort of) Easy: http://www.paul-moore.com/files/lj/libse
Just a few minutes ago we announced the second release of the libseccomp library, version 1.0.0. The libseccomp library is designed to provide an easy to use, platform independent, interface the Linux's syscall filtering mechanism: seccomp.
Significant changes in this release include:
- The API is now context-aware; eliminating all internal state but breaking compatibility with the initial 0.1.0 release. The major version number has been bumped with this release to allow both version to coexist on the same system.
- Added support for multiple, simultaneous build jobs and verbose build output. This should not affect individual developers, but it should make life easier for packagers.
Once again, thanks to everyone who has submitted suggestions, provided testing
help, and contributed patches to the project.
SourceForge project page: http://sourceforge.net/projects/libsecco
Direct download: http://sf.net/projects/libseccomp/files/l
One of the most common complaints I hear about the labeled networking access controls in Linux is that users don't know how to configure them for their given scenario. To help solve that problem I'm going to try and document some basic use cases and the associated labeled networking "configuration recipes".
To start off, I'm going to tackle a fairly common use case: a SELinux system with different MLS/MCS labels connected to multiple, single label networks. Imagine a SELinux based system providing services, e.g. a web server, to multiple different networks, each consisting of label un-aware clients, e.g. Windows desktops, operating at different securit labels. For this example, we will assume that the SELinux system is connected to two single label networks, one labeled at s1:c3,c5 (eth0,10.0.0.0/24) and the other labeled at s2:c4,c6 (eth1,10.0.1.0/24). To complete the example, we will also assume that the SELinux system is running at least one application which needs to connect to the local system (localhost) at different levels.
The first step is to configure NetLabel to label incoming traffic on the unlabeled, single label networks.
# netlabelctl unlbl add interface:eth0 address:0.0.0.0/0 \ label:system_u:object_r:netlabel_peer_t:s1:c3,c5 # netlabelctl unlbl add interface:eth1 address:0.0.0.0/0 \ label:system_u:object_r:netlabel_peer_t:s2:c4,c6
In general we don't have to worry about the outbound traffic in this case since NetLabel sends all traffic unlabeled by default, but let's go ahead and assume that isn't the case for the sake of demonstration. The commands below remove the default mapping and instruct NetLabel to send unlabeled traffic to both of the single label networks as well as any networks not explicitly specified (both IPv4 and IPv6).
# netlabelctl map del default # netlabelctl map add default address:10.0.0.0/24 protocol:unlbl # netlabelctl map add default address:10.0.1.0/24 protocol:unlbl # netlabelctl map add default address:0.0.0.0/0 protocol:unlbl # netlabelctl map add default address:::/0 protocol:unlbl
Next we want to configure the system to send labeled traffic to itself, so we need to tell NetLabel to send CIPSO labeled traffic to all of the system's addresses (in this case that would be 10.0.0.2, 10.0.1.2, and 127.0.0.0/8). However, first we need to configure a CIPSO DOI for this local traffic labeling; in this example we will use DOI #32 and the pass through DOI type with the enumerated (tag #2) and restricted bitmaps (tag #1) tags.
# netlabelctl cipsov4 add pass doi:32 tags:2,1 # netlabelctl map add default address:10.0.0.2 protocol:cipsov4,32 # netlabelctl map add default address:10.0.1.2 protocol:cipsov4,32 # netlabelctl map add default address:127.0.0.0/8 protocol:cipsov4,32
Now we should have all of the labeling configuration in place and it is just a matter of making sure your SELinux configuration/policy is correct for the accesses you want to allow. One important thing to remember is that you likely will want to use the semanage tool to set the SELinux label for the single label interfaces; this will ensure that only traffic labeled as s1:c3,c5 can traverse the eth0 interface and only traffic labeled as s2:c4,c6 can traverse the eth1 interface.
# semanage interface -a -t netif_t -r s1:c3,c5 eth0 # semanage interface -a -t netif_t -r s2:c4,c6 eth1
At this point, if you haven't already, you should double check your SELinux policy as you will most likely need to add some custom policy modules to match your new labeled networking configuration, but thankfully that is something which has gotten much easier the past few years and already has plenty of good documentation available. You may also want to start investigating the xinetd LABELED configuration option as a way of starting server applications at the label of the incoming connection request; it can be a very useful option for systems like this where you have client requests coming in at different levels.
Good luck, and don't hesitate to add any problems or questions you may have in the comments.
Now, before I got into the details of "how", I just want to be clear that what I'm about to tell you isn't really a secret, it just hasn't been very well publicized. After all, I'm not sure how it could be a secret when the code is available for anyone and everyone to review and inspect. Further, the "how" is even documented in the netlabelctl manpage, so if this capability is NetLabel's best kept secret it has clearly been hiding in plain sight.
Enough of the "secret", let's explain how to get this working. First off, if you're going to try this on your own system (any modern Linux distribution that supports SELinux and NetLabel should work), you might want to grab a copy of the getpeercon_server test tool that I've used in the example below; instructions for building the test tool are at the top of the file. Once you've got everything built and you've verified that your SELinux and NetLabel installation is working as you would expect, you need to start off by configuring the CIPSO Domains Of Interpretation (DOI). For this example we are going to create two DOIs, one using the standard, MLS-only passthrough type and the other using the local-connection-only full SELinux type. Don't forget that you can always check the netlabelctl manpage for more information on the commands below.
# netlabelctl cipsov4 add pass doi:1 tags:1
# netlabelctl cipsov4 add local doi:2
# netlabelctl -p cipsov4 list
Configured CIPSOv4 mappings (2)
DOI value : 1
mapping type : PASS_THROUGH
DOI value : 2
mapping type : LOCAL
# netlabelctl map del default
# netlabelctl map add default address:0.0.0.0/0 protocol:unlbl
# netlabelctl map add default address:::/0 protocol:unlbl
# netlabelctl map add default address:127.0.0.1 protocol:cipsov4,2
# netlabelctl map add default address:10.250.2.92 protocol:cipsov4,1
# netlabelctl -p map list
Configured NetLabel domain mappings (1)
protocol: CIPSOv4, DOI = 2
protocol: CIPSOv4, DOI = 1
# ./getpeercon_server 5000
-> running as unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(10.250.2.92,system_u:object_r:netlabel_peer_t:s0)
Connected to 10.250.2.92:5000
-> connection closed
-> waiting ... connect(127.0.0.1,unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023)
Connected to 127.0.0.1 5000
-> connection closed
-> waiting ...
Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.
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-platfor
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/Road
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.
So, with a new job comes a new email address; you can continue to send me email at email@example.com, but now you can also reach me at firstname.lastname@example.org.
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.