You are viewing paulmoore

My LPC and LSS 2012 Presentations

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_security-pmoore-lpc2012-r1.pdf
Syscall Filtering Made (sort of) Easy: http://www.paul-moore.com/files/lj/libseccomp-pmoore-lss2012-r1.pdf

counter create hit

New Release for libseccomp

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/libseccomp
Direct download: http://sf.net/projects/libseccomp/files/libseccomp-1.0.0.tar.gz/download

counter create hit

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.

counter create hit
Perhaps one of the largest shortcomings of the CIPSO network labeling protocol when used with SELinux is the fact that it can only convey the SELinux MLS attributes across the network.  There are plenty of good reasons for this: strict conformance with protocol specification, limited space in the IPv4 header, interoperability with non-SELinux systems, etc.  However, regardless of the reasons why, there will always be use cases where it would be very nice to have the full SELinux label without the performance, scalability and management overhead of labeled IPsec.  While I can't say I have solution for all of those use cases, today I am going to let you in on one of NetLabel's best kept secrets: NetLabel and CIPSO can convey the full SELinux label over local connections, and it has been able to do so for years.

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

After you've setup the CIPSO DOI's you need to configure NetLabel to send traffic using these new DOIs.  In our example we are going to configure the system such that traffic sent to 127.0.0.1 (localhost) will use DOI #2, the local-only full SELinux label DOI, and traffic sent to 10.250.2.92 (the system's eth0 address) will use DOI #1, the normal MLS-only DOI.  Don't forget that we first need to remove the default unlabeled mapping so we can use the address selectors.

# 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)
domain: DEFAULT
address: 127.0.0.1/32
protocol: CIPSOv4, DOI = 2
address: 10.250.2.92/32
protocol: CIPSOv4, DOI = 1
address: 0.0.0.0/0
protocol: UNLABELED
address: ::/0
protocol: UNLABELED

With that we're finished, now it's time to test it out.  Testing is quite simple, make sure you have a TCP client like telnet or netcat installed and then start the getpeercon_server test tool you built earlier; in this example getpeercon_server is listening on TCP port 5000.

# ./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 ...

It works! When we connected to 10.250.2.92 we saw the familiar "netlabel_peer_t" type, but when we connected to 127.0.0.1 we saw the full SELinux label of our telnet client process, "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023".  Go ahead and try it out for yourself, just remember that you can only use the "local" DOI type on network connections that run over the loopback network interface.
counter create hit

Announcing the libseccomp Project

This morning we announced the first release of the libseccomp library, version 0.1.0. The libseccomp library is designed to provide an easy to use, platform independent, interface the Linux's syscall filtering mechanism: seccomp. Linux Weekly News wrote up a nice summary of the project that I would encourage you to read as it provides a basic introduction to seccomp and the libseccomp API. For those of you interested in playing with seccomp/libseccomp, you will need Linux 3.5-rc1 or later, and the libseccomp library which you can download from the links below.

I want to say a special thanks to everyone who has submitted suggestions, provided testing help, and contributed code to the project; your help made it much easier to get to this point.

counter create hit

Wrapping Up The 2011 Linux Security Summit

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

Twitter Too

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

New Email Address Part Two

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

New Email Address

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

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.

Tags:

counter create hit

Profile

paulmoore
paulmoore
Paul Moore

Latest Month

September 2012
S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow