I was kind of surprised and also happy to see that Dan Kegel’s The C10K Problem is still being actively maintained after seven years (with recent updates covering Evgeniy’s kevent work). That’d have to make it one of the oldest active Linux documents on the Internet. Which is like how people describe volcanoes.

I’ve glanced through a copy of the new SELinux book, SELinux by Example, and it looks to be very comprehensive. I’d say it’s the best current resource on the subject.

FC6 will include some SELinux usability improvements, most notably, a new GUI desktop tool setroubleshoot, which was inspired by the idea of the Gnome Bug Buddy. The idea is to notify the user when something goes wrong (e.g. an AVC denial), and present them with a clear explanation and an easy means to do something constructive in response. In addition to the detailed design documentation at the above link, setroubleshoot has been blogged about by Karl MacMillan and Dan Walsh.

Setroubleshoot Alert.

There’s also a new facility for maintaining the correct labels on files, restorecond, which runs in the background and relabels files automatically in certain cases (e.g. for files being served by Apache). This is of course a trade-off between security and usability, and is entirely configurable via

/etc/selinux/restorecond.conf

It’s really great to see these kinds of improvements being made. Security is a hard problem, and such problems take a lot of time and effort to solve effectively. We’re getting there.

I’ve created a new account, for non-work related stuff. Feel free to add me.

I received an OLPC test board on Friday and spent much of the weekend playing with it.

The test board seems to work as expected, with a couple of minor BIOS bugs. I haven’t had much luck with the OPLC Fedora build images, which I gather contain the neat UI stuff, although normal Fedora development snapshots seem to be ok. I’ve only done text mode so far (not sure if I’ll even bother trying to get Gnome running with 128K of RAM).

Some possibly helpful tips:

• I’m using a portable Segate 60GB USB hard drive, which has a second USB cable just for power. This is useful as the OLPC board doesn’t have enough power for the drive via any of its onboard USB ports, and you need the boot drive connected directly due to a BIOS bug. So, I can connect the power-only USB cable to a powered hub and the data cable to the board.
• For wired ethernet, I’m using an old SMC 2208 USB ethernet adapter, which uses the rtl8150 driver (it’s the very last item in the driver selection dialog during the Fedora install).
• I also have a new D-Link DUB-E100 USB ethernet adapter, which according to online docs, should work with the usbnet driver, although I haven’t had any luck with that.

It looks like there are many interesting and novel engineering problems to be solved for this project — certainly no shortage of solid challenges for software and hardware hackers. All kinds of useful development info is being added to the OLPC Trac system.

The Call for Papers for the 2007 SELinux Symposium has been announced. Submissions close on October 9th.

The symposium will be held in Baltimore again, from March 12-16, 2007.

Joshua Brindle has analyzed the recent /proc local privilege escalation vulnerability, CVE-2006-3626, and posted that SELinux targeted policy prevents exploitation.

It’d be an interesting and useful exercise to go back through historical vulnerabilities and determine how many of them would be mitigated by SELinux and similar technologies (Exec-shield, PIE etc.).

Mark Cox wrote an interesting paper, Risk Report: A year of Red Hat Enterprise Linux 4, which mentions that SELinux blocked the Lupper worm (also noting that that the policy version shipped by default would not have blocked a modified version of the worm).

Update:
SELinux mitigation confirmed by SANS. They also mention mounting /proc as nosuid as a workaround.

Here’s a summary of the SELinux-related changes in the recently released 2.6.17 kernel.

Alexey Dobriyan

• Endian fix, for confusion of ntohs() & htons().

Darrel Goeddel

• Support for context-based audit filtering, allowing various components of the SELinux security context to be used as audit filter selectors.

Steve Grubb

• Hardwire important SE Linux events to the audit subsystem.
• Various audit/SELinux integration.
• Only gather SELinux context strings for inodes if an audit event is being generated, makes considerable performance savings.

Serge Hallyn

• Check for failed kmalloc in security_sid_to_context(), nice bugfix

Dustin Kirkland

• Capture SELinux subject/object context information, which distinguishes subjects and objects in audit records.

Ingo Molnar

• Semaphore to mutex conversion.

James Morris

• Add slab cache for inode security struct. This saves a lot of kernel memory (more than 500K on a 64-bit machine).
• Various selinuxfs cleanups.

Jamal Hadi Salim

• Update SELinux handling of XFRM Netlink messages.

Stephen Smalley

• Disable automatic labeling of new inodes when no policy is loaded. This stops SELinux from setting the default ‘unlabeled’ label on new disk inodes if no policy is loaded, to work around some obscure cases where systems later have incorrect (but safe) labels on files.
• Fix sb_lock/sb_security_lock nesting, detected by Ingo’s lock validator.
• Clear selinux_enabled flag upon runtime disable, bugfix.

Ron Yorston

• Fix MLS compatibility off-by-one bug

Catherine Zhang

• TCP/UDP getpeersec. This provides a mechanism for applications to determine the security context of peers they’re communicating with, via IPSec xfrm labeling. For TCP, there’s a new SO_GETPEERSEC option for getsockopt() which returns the peer security context. For UDP, the peer security context may be retrieved on a per-message basis after setting a new IP_PASSEC socket option, then accessing the value via CMSG auxiliary data.
• Authorize deletion of IPSec/xfrm labeling policies.

LWN has created a survey to elicit feedback on the quality of the 2.6 kernel series. This is a really important opportunity for the kernel development community to obtain data on how the development process is working, so please consider taking the survey. The results will be presented at the kernel summit by Jon Corbet.

There’s a beta Google Earth client for Linux, which sounds like fun, except, like Picasa, it doesn’t work out of the box with SELinux.

Dan Walsh has provided the following simple workaround:

chcon -t unconfined_execmem_exec_t /usr/local/RealPlayer/realplay.bin
execstack -c /usr/local/google-earth/libcrypto.so.0.9.8

I don’t know why these apps need executable memory, and whether it’s truly safe to make these changes, as I don’t have the source to them.

Update:
Dan has more analysis here.

Update #2:
Dan received some email from google developers: looks like the problem snuck in at the last minute, and a fix is expected in the next release. Also, I installed it on my FC5 laptop running SELinux in enforcing mode and saw no problems, so it’s not affecting everyone.

I wrangled an invitation to Mugshot, the new super secret mashup project which Havoc Pennington and co. have been working on. It’s pretty addictive. Not sure how to explain it.

Looks like someone definitely read these words of wisdom.

Edit: here’s an interesting blog entry on Mugshot by Fred Stutzman.

Many people will be trying out Google’s Picasa under Linux. Unfortunately, there’s no SELinux policy for the application yet, and Google have been advising people to disable SELinux on Fedora to run Picasa.

If affected, you do not need to disable SELinux.

A simple filesystem labeling workaround has been described in the following post:

http://groups.google.com/group/Google-Labs-Picasa-for-Linux/msg/06f6a1465a712dbc

# Set the executable module exception on *.so *.so.* and *.dll files

> find /opt/picasa -type f -iname '*.so' -o -iname '*.so.*' -o -iname '*.dll' -exec  chcon -t textrel_shlib_t {} \; 

It appears that some of the libraries they distribute require the execmod permission, which is not granted by default under SELinux. The above workaround above relabels the supplied libraries so that SELinux policy will consider them “safe” to perform operations constrained by the execmod permission. This in fact may be unsafe, although this workaround is certainly better than completely disabling SELinux.

You can read more about the details of execmod Ulrich Drepper’s document SELinux Memory Protection Tests.

Based on Ulrich’s commentary, it seems reasonable to assume that some element of the Picasa code being blocked by the SELinux policy needs to be reworked for security reasons. I’m not sure exactly which component(s) may be generating the policy violations, although it may of course be one of the third-party libraries. Ideally, we’ll be able work with the Google and/or third party developers to get the issue resolved correctly.

If you have any further information on this, contact the Fedora SELinux developers via the Fedora SELinux mailing list.