Watch out for shadow-4.1.5-r1 and pambase-20120417

I recently bumped shadow-4.1.5-r1 and pambase-20120417. bug #412721 has been filed about people being locked out after the update.

The fix is to run dispatch-conf. The reports are unclear, but you might not get any message from emerge that it is necessary. If dispatch-conf doesn't update anything, make sure to manually re-emerge pambase.

What's going on? /etc/pam.d/{login,passwd,su} are being moved from shadow package to pambase, so they can be shared with hardened-shadow. They are not really shadow-specific, but Gentoo-specific, so it makes sense to make pambase own those files.

www-client/chromium and libjpeg-turbo

Recently Gentoo bug #412031 (">=www-client/chromium-18.0 should not force the media-libs/libjpeg-turbo dependency") has been filed. Samuli did the right thing and closed it, but I'd like to use this as an opportunity to explain the issue in more detail.

The original bug is #393471, filed by Gentoo Chromium team member Mike Gilbert four months ago and fixed in February. An optimization done in WebKit JPEG decoding code (which speeds up JPEG decoding by up to 2x) assumed that the code will run against the same version of JPEG library it has been compiled with. In general such assumptions do not hold (with the note of SONAMEs, i.e. same library SONAME should mean it's binary-compatible; more on that later), but Google Chrome bundles all of those third-party libraries anyway, so for Google it's true.

I started a discussion on chromium-dev mailing list, and also had direct e-mail exchange with developers doing the WebKit and libjpeg-turbo changes. The end result is we'd either have to keep a local patch in Gentoo to revert the optimization, or just always depend on libjpeg-turbo.

Of course the most cool would be to do the optimization The Right Way, by doing runtime detection of JPEG extensions, as made possible by DRC, libjpeg-turbo developer and explained in bug #393471 comment 23. jcstest.c in libjpeg-turbo source tree indeed shows how to do that. The only reason I haven't done that yet in WebKit is lack of time (it's not just producing the patch; compiling WebKit and running its layout tests takes a lot of it; and then dealing with any possible breakages), but I plan to do that in the future (help is welcome).

Speaking about The Right Way, another broken thing is that libraries that have the same SONAME (in this case libjpeg and libjpeg-turbo) behave differently when using JPEG extensions. You may recognize the libpng "breakages", but it seems to me libpng upstream actively cleans up the interface of the library, and it obviously updates SONAME accordingly. That's a good thing.

Hopefully it's now more clear why the Gentoo package www-client/chromium depends on libjpeg-turbo and not virtual/jpeg.

Experimenting with SELinux

Recently I started experimenting with SELinux and created a new VM for that. I've used the excellent Gentoo SELinux Handbook and mostly got things running. I also submitted bug #411005, bug #411365, and bug #411377 to make it even better.

SELinux may seem scary or complicated at the first glance, but my experience so far was pretty good. I did encounter some AVC denials, but that was fine. Here are my general notes about running a SELinux system:

1. UNIX permissions work normally. If UNIX permissions deny access, SELinux rules are not checked. Access is just denied, as expected. SELinux rules can result in more denials, but can never allow more than UNIX permissions.
   
2. Permissive mode is really useful. In that mode the denials are only logged, not enforced. The system should work as usual, and you have chance to note and fix eventual problems. You can actually switch between permissive and enforcing on the fly (setenforce 1, setenforce 0), so you can experiment whether things would work in enforcing mode and quickly switch back otherwise.
   
3. Targeted policy is recommended for desktop systems. It's part of general advice to "start small", but desktop systems have many more available applications anyway. Usually servers are minimal installations, so it's easier to write complete strict policy for them. Targeted SELinux policy uses unconfined_t context by default, which has no restrictions at all. Only selected applications have a specific policy just for them.
   
4. You don't need to worry about SELinux users with targeted policy. Another part that makes SELinux more complicated is that normal Linux users are mapped to SELinux users. This is important when using strict policy, but with the targeted one everyone is just mapped to unconfined_u.
   
5. Most access decisions are made based just on the type. Usual SELinux context, e.g. unconfined_u:object_r:user_home_t may seem quite complicated. However, corresponding allow rule would most likely only need to mention the type, i.e. user_home_t (to be precise, two types: types of the object and type of the subject).
   
6. Many confusions are just matter of vocabulary. For example, there is no practical difference between domain and type (source). My understanding is that domains are types used to confine processes, so every domain is a type, but not every type is a domain.
   
7. Allow rules are actually pretty simple. For example "allow example_t self:process execmem;". Ignore the syntax, the meaning of each rule is really straightforward, and I think it's no different with alternative MAC (Mandatory Access Control) implementations. And when writing a policy for specific domain (in this case example_t), all of the rules are going to start with "allow example_t ...".

For further reading, I recommend SELinux from the inside out and Breaking the Ice with SELinux.