July 18th, 2009 | Tags: , , , , , ,

This is just to note that the Red Hat Security Response team have issued a preliminary comment on the 2.6.30 kernel null pointer vulnerability, as a comment in the associated bugzilla entry:

From Eugene Teo (Security Response Team)  2009-07-17 07:23:57 EDT

The Red Hat Security Response Team is aware of the Linux kernel local privilege
escalation exploit that is published in a number of security mailing lists and
websites. The flaw identified by CVE-2009-1897 is a null pointer dereference
vulnerability in the tun_chr_poll() function of the Linux kernel, introduced
via the upstream git commit 33dccbb0. This flaw affects kernel versions between
2.6.30-rc1 and 2.6.30-rc3 2.6.31-rc3 , and was addressed via the upstream
git commit 3c8a9c63.

The flaw affects only the Red Hat Enterprise Linux 5.4 beta kernel as the
upstream git commit 33dccbb0 was backported to the kernel as a normal bug fix.
We will be addressing this flaw in a future update to the beta kernel. It is
also possible to mitigate this flaw by ensuring that the permissions for
/dev/net/tun is restricted to root only.

The default SELinux policy, in Red Hat Enterprise Linux 5, allows processes in
the unconfined domains to map low memory in the kernel. The exploit did not
bypass the null pointer dereference protection in the Linux kernel. However, we
are updating the selinux-policy package to change this default configuration,
so that it prevents the unconfined processes from being able to map the low
memory. See bug 511143 for more information.

This issue does not affect any other released kernel in any Red Hat product.

In addition, future updates to Red Hat Enterprise Linux kernels may include the
'-fno-delete-null-pointer-checks' gcc CFLAGS. See:
http://git.kernel.org/linus/a3ca86aea507904148870946d599e07a340b39bf

We would like to thank Brad Spengler for bringing these issues to our
attention.

Note that I’m not a member of the security response team: I’m cc’d on the bug and noticed the statement when it was posted.

It is also worth highlighting that you should ensure that the permissions on

/dev/net/tun

are correct.  It should look like this:


# ls -l /dev/net/tun
crw------- 1 root root 10, 200 2009-07-07 09:52 /dev/net/tun

It’s possible that some VPN package may change the permissions on this.

In terms of the SELinux aspect of the exploit, I’ve posted a brief comment in the LWN thread here.

Yes, there was a mistake in the SELinux policy, which allowed the unconfined user to bypass the mmap_min_addr check, which otherwise would have been enforced if the check was enabled (many disable it to get wine etc. working, btw, google disable mmap_min_addr).

This is being fixed in the policy.

The lesson learned here is that more careful review of policy changes needs to happen, and to ask the question as to whether the policy is capable of weakening default security.

The LSM interface is theoretically designed to only allow further restriction of access, but this is a special case, where we are applying policy to a kernel compilation option which can also have its value set via a sysctl. It’s not a typical “access this resource or not?” decision.

The policy bug is now fixed in the selinux-policy-2.4.6-252.el5 package.

The challenge now is to try and ensure that we don’t see this class of problem crop up again, for unusual cases such as this where the normally “restrictive” mode of LSM (i.e. where permissions can only be further restricted) does not apply.  We may need to rethink how this is managed in the kernel to reduce the possibility of such issues in LSM module policy, as the LSM API here appears to be violating the Hard to Misuse design principle.

Comments Off
Kuala Lumpur

Kuala Lumpur

I just noticed that the Call for Participation for FOSS.my 2009 is now open, until August 15th.  I spoke at the inaugural event last year, and had a great time.  Held in Malaysia, this is a true grass-roots conference.  It’s modelled somewhat on other community events such as LCA and FOSS.IN, and probably the leading such event for Southeast Asia.

The conference will be held on the weekend of the 24th and 25th of October, immediately following the Japan Linux Symposium and the Kernel Summit.  If you’re visiting the region for either of the Tokyo events, Malaysia is relatively close-by, and there are several good budget airlines in the region.  I’d highly recommend submitting a proposal or simply attending.

Kuala Lumpur is certainly a great city to visit, too.

Comments Off
July 1st, 2009 | Tags:

I’ve uploaded the slides from essentially all of the talks I’ve given to Slideshare. This is likely more useful than my previous strategy of dumping them in a directory and leaving the rest up to search engine bots.

Click here for the full list of slides. They are all published under the Creative Commons attribution share-alike license.

One interesting slide title, which I’d forgotten about, is Kernel Security for 2.8, from the 2004 Kernel Summit. This was from when we were still expecting a 2.7 development kernel leading to a 2.8 stable kernel — I think Linus announced the change in development model at that summit.

Included in this set of slides are several introductory and deeper technical overviews of SELinux; I hope they are useful for people who are looking for information for themselves, or if making their own slides. As the license suggests, please feel free to copy and extend them (but note that the older ones are going to be more out of date).

Comments Off
June 30th, 2009 | Tags:

I mean, SLUGs…

Paul Wayper gave a couple of talks on SELinux at this weeks’ SLUG meeting, and includes links to a couple of very useful slide decks:

The sysadmin slides look particularly useful, as they focus on solving common issues such as running FTP/SAMBA/Apache servers, and provide some very useful general tips, such as looking in the audit log and using policy booleans for high-level policy tweaking.

These slides may be the best, short introduction for sysadmins on the topic that I’ve seen. It’s a difficult thing to get right.

Comments Off
June 26th, 2009 | Tags:

Here’s an update on the major changes to the kernel security subsystem for the 2.6.30 kernel.

  • TOMOYO
    The TOMOYO security framework from NTT was merged. This is the first significant LSM scheme to be merged since SELinux in 2003. TOMOYO is characterized by its targeting of non-technical users, where security policy is automatically generated with a “learning mode” tool. This scheme utilizes pathnames for determining access to filesystem objects. Another interesting feature is that a domain, i.e. an active subject which acts on objects, is defined as a history of process invocations, rather than a single process. This allows policy to be applied to a particular branch of processes in the system. For example, an access permitted for init->httpd->perl may not be permitted for init->httpd->bash. Sample policy may be found here.
  • IMA
    IBM’s Integrity Measurement Architecture was also merged. This uses the TPM to verify and store cryptographic checksums of files used by the system, i.e. measurement. If a measured file has been modified on disk, this will be detected and stored permanently in the TPM. The aim is to help detect attacks based on modifying files—such as executable binaries or configuration files—although it cannot detect runtime attacks, and requires checksums to be known in advance for the full system startup chain. Files to be measured may be specified in a policy loadable via securityfs.
  • Remove Old SELinux Network Controls
    The original SELinux network controls were deprecated by the iptables-based Secmark system several years ago, although they remained available via the compat_net option for the likely few people who were using them. The old code has now been removed entirely, and users should transition to Secmark: Paul Moore has written a detailed guide for this.

The remaining changes were primarily bugfixes and enhancements across most parts of the security subsystem, including SELinux, SMACK, and keys.

Paul and I are finalizing the schedule for the security microconf at the upcoming Linux Plumbers Conference. It’s looking like a great line-up at this stage—stay tuned for more details soon.

Comments Off
June 24th, 2009 | Tags:

Just a reminder for SELinux developers and anyone interested in the internals of SELinux that the SELinux Developer Summit CfP closes on July 1st, which is about a week away.

SELinux logo

Details of the CfP are here. Don’t forget to join the event mailing list if you’re attending.

Proposals for presentations, lightning talks, and development sessions should be submitted via email per the instructions in the CfP. Proposals do not need to be especially detailed: if you have a good idea, simply send it in.

mystery object

For reading this, you are rewarded with a mystery object (pictured above). See if you can figure out what it is before clicking on it and reading the comments @ flickr.

Comments Off
June 16th, 2009 | Tags:

In the process of preparing my talk for KCA, I re-read the classic paper: The UNIX Time-Sharing System by Ritchie & Thompson. This paper was revised several times between 1973 and 1978, and the authors’ observations are well worth remembering:

Perhaps paradoxically, the success of the Unix system is largely due to the fact that it was not designed to meet any predefined objectives. The first version was written when one of us (Thompson), dissatisfied with the available computer facilities, discovered a little-used PDP-7 and set out to create a more hospitable environment [...] We have not been faced with the need to satisfy someone else’s requirements, and for this freedom we are grateful.

Three considerations that influenced the design of Unix are visible in retrospect.

First: because we are programmers, we naturally designed the system to make it easy to write, test, and run programs. The most important expression of our desire for programming convenience was that the system was arranged for interactive use, even though the original version only supported one user. We believe that a properly designed interactive system is much more productive and satisfying to use than a “batch” system. Moreover, such a system is rather easily adaptable to noninteractive use, while the converse is not true.

Second: there have always been fairly severe size constraints on the system and its software. Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy, but also a certain elegance of design. This may be a thinly disguised version of the “salvation through suffering” philosophy, but in our case it worked.

Third: nearly from the start, the system was able to, and did, maintain itself. This fact is more important than it might seem. If designers of a system are forced to use that system, they quickly become aware of its functional and superficial deficiencies and are strongly motivated to correct them before it is too late. Because all source programs were always available and easily modified on-line, we were willing to revise and rewrite the system and its software when new ideas were invented, discovered, or suggested by others.

It’s clear that the success of Linux (and FOSS more generally), is underpinned by these principles.  These principles are not merely about technology; they’re a way of thinking about technology and the people who create and use it.

Comments Off
June 10th, 2009 | Tags:

sVirt (MAC security for Linux Virtualization), which I’ve previously discussed here, and formally presented at LCA in January, was released today as an integral part of virtualization in Fedora 11.

If you’d like to give it a spin, simply download and install Fedora and use the GUI admin tools to create a new virtual machine.

Thanks again to Dan Walsh, Dan Berrange and all the developers who helped with input and the heavy lifting work of completing the userland code. It still amazes me how fast things move in FOSS.

As mentioned in my last+1 post, Dan W will be talking on this topic at the upcoming LinuxCon.

Further developments in this area are already underway, and you can expect to hear about them in the coming months—see the talk slides for possible hints.

Comments Off
May 29th, 2009 | Tags:

Dan Walsh recently introduced SELinux sandbox. This is a mechanism for launching untrusted applications from the command line, which uses a strict MAC policy to isolate the executed application from the rest of the system. There’s been a good discussion of the topic LWN, and I thought it might be worth highlighting a few points.

Firstly, this sandboxing scheme is not a separate package. It’s an addition to the standard SELinux security policy to define the sandboxed domain (sandbox_t) coupled with a script to set up the environment and launch applications in the sandboxed domain.

The idea for this came out of a few emails following a recent discussion about extending seccomp for more generalized sandboxing. Essentially, the question was asked "what can we do with SELinux and simple sandboxing?", and the result is now available in Fedora development. If you update to the latest policycoreutils and selinux-policy packages, it should simply be there ready to go.

The security policy for the sandbox_t domain is designed to provide the sandboxed application with only the absolute minimum set of permissions required to run. It can load shared libraries, for example, although a future refinement could provide an option to run only static binaries. It cannot interact in an ad-hoc manner with the rest of the system. A scratch tmpfs filesystem may be optionally mounted for the application if required, and unique MCS labels are used to separate sandboxes from each other. Another future refinement will likely include launching sandboxes in private namespaces.


# sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c226,c674

The above shows how the id command launched via the new sandbox utility is running in the sandbox_t domain, with MCS categories c226 and c674. The values of these don’t matter, as long as they’re unique on the system.

As root (and note that this is not designed to be run as root, but for demonstration purposes it helps to show the confinement of privileges if they exist), you can’t do anything special via sandbox:

# sandbox cat /etc/shadow
/bin/cat: /etc/shadow: Permission denied

# sandbox touch /tmp/moo.txt
/bin/touch: cannot touch `/tmp/moo.txt': Permission denied

In fact, you can’t open any files on the global system.

Ambient authority describes the form of authority commonly seen in general purpose operating systems. This form of authority is what allows, for example, a user on a Linux system to open any file for which she has read access, whether she needs to open the file or not. It is seen as problematic in establishing strong security, due to problems such as The Confused Deputy, where authority (i.e. the ability to perform an action) is arbitrarily escalated throughout the system.

(For a particularly clear explanation of these concepts, they are covered in the first ten minutes of this talk by David Wagner).

When an application is launched via sandbox, with no inessential permissions, as much ambient authority as is possible has been removed by SELinux MAC. Instead, authority is explicitly provided to the sandboxed application via a pipe file descriptor handed to it via the launching process (i.e. the standard Unix scheme of constructing pipelines).

Note carefully the difference between these two commands:

# wc -l /etc/shadow
43 /etc/shadow

and


# cat /etc/shadow | wc -l
43

In the first example, the wc application directly opened the file /etc/shadow for reading. It used ambient authority to do this.

In the second example, wc was handed a file descriptor which was already opened by the calling process, and did not require any ambient authority to read the data in the file: the authority was explicitly tied to the file by the caller, and wc was entirely unaware of which file it was reading. wc in this case does not need any permissions except to access the file descriptor passed by the caller. (It still has ambient authority, however, it just didn’t need to use it here).

Running the above with SELinux sandboxing in effect:


# sandbox wc -l /etc/shadow
/usr/bin/wc: /etc/shadow: Permission denied

and


# cat /etc/shadow | sandbox wc -l
43

Note that wc now has no authority now except as invoked by the calling process and passed via the sandbox. In other words, it does not have ambient authority when invoked via the sandbox.

This is a very simple and powerful concept for security purposes, as it is possible to define strict information flows between applications in a dynamic and controlled manner, without the need for additional global security policy. It’s inherently Unix-y, too.

There are many potential applications of this form of sandboxing, particularly where you need to process information between different security realms (e.g. incoming mail which needs to be passed through a chain of scanning and filtering applications), and for dealing with large and complicated applications processing arbitrary untrusted data.

Keep an eye on Dan’s blog for upcoming work on desktop security with SELinux sandboxing.

Comments Off
May 29th, 2009 | Tags:

Several Linux security events are planned in association with LinuxCon this year in Portland, Oregon.

  • 2009 SELinux Developer Summit
    The CFP for this event has just been published. The developer summit will be held on the 20th of September as an ancillary event of LinuxCon. This is a one-day event, and developers are encouraged to submit proposals around the primary topics of extensibility and usability. We’re hoping to have a flexible format this year, perhaps with half a day of talks and then half a day of hack sessions. Note that all attendees need to be registered for LinuxCon, and that earlybird registration ends this Monday, June 1st. Also, please subscribe to the event mailing list if you’re planning to attend, so we can estimate numbers. More details are available at the summit web page.
  • Security Microconf
    A security microconf will be held at the co-located Plumbers Conference. The Call for Topics ends on June 15th, and anyone doing interesting work in Linux security should consider submitting a proposal. Also see the LWN topic discussion and Paul McKenney’s recent blog entry on the event.
  • LinuxCon Talks
    There are several security-related talks at LinuxCon itself:

    I’ll be giving a LinuxCon talk on adding extended attributes support to NFSv3, presenting a prototype implementation (based on the GPL IRIX code) for discussion. xattrs are a very common feature in Unix and Linux filesystems, but there is no standard for them, nor for conveying them over NFS. NFSv4 supports “named attributes”, although this is based on the Solaris extended attribute scheme (subfiles), and somewhat incompatible the simple name/value string-based xattrs supported by Linux, BSD, IRIX etc. It would be nice to have Linux-style xattrs supported in NFSv3, with the current work then potentially forming the basis for a future NFSv4 protocol extension. If you’re interested in this stuff, please consider attending and helping with the discussion.

Comments Off