codeblog code is freedom — patching my itch


Farewell Breezy

Filed under: Blogging,Security,Ubuntu — kees @ 6:46 pm

Breezy is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 18 hours, 49 minutes, and 4 seconds on 108 builds related to the roughly 64 breezy-security updates I was involved in publishing. So far, Dapper is at 132 builds totaling 19:59:40, and Edgy is at 142 builds totaling 23:32:28. These times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the PPC machine, etc. Even if it’s a bit incomplete, I think it’s fun to be able to point to some hard numbers about CPU time spent on Breezy updates. :)

Thank you Breezy! You have housed my MythTV installation very nicely, but now it’s time for some long over-due upgrades…

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License


AppArmor now in Feisty

Filed under: Security,Ubuntu — kees @ 11:03 am

With the help of Magnus Runesson, Jesse Michael, Martin Pitt, and many others, I’ve got AppArmor packaged and uploaded into Feisty universe. Prior to this, admins interested in a Mandatory Access Control system in Ubuntu only had SELinux available; now we have more of a choice. For anyone wanting to try out AppArmor, you will need to compile the modules, and install the base packages:

sudo apt-get install apparmor-modules-source dpatch
sudo m-a -v -t prepare
sudo m-a -v -t build apparmor-modules
sudo m-a -v -t install apparmor-modules
sudo apt-get install apparmor apparmor-utils apparmor-profiles libterm-readline-gnu-perl

With the default profiles, you can see one quick example of a confined process. Try doing this:

ping localhost >/dev/null &
sudo ps aZ | grep ping

In the first column, you should see what profile is being used to confine the process:

/bin/ping 14351 pts/14 S 0:00 ping localhost
unconstrained 15381 pts/14 S+ 0:00 grep ping

The list of active profiles can be seen as root in /sys/kernel/security/apparmor/profiles, which are loaded from /etc/apparmor.d/.

To confine a process, use aa-autodep and aa-logprof. For example, I wanted to confine my PDF document browser to only use /tmp (since I tend to only use it when browsing PDFs online):

  • First, I create an empty profile in “complain” mode: sudo aa-autodep evince
  • Next, I run evince like I normally would, including as many actions as I can think of (printing, preferences, help, etc). Watching the output of dmesg you can follow the trail of all the actions evince is taking. When I’m finished, I quit evince.
  • Next, I run aa-logprof, which runs through all the kernel audit output and offers suggestions on what to allow from evince. Where appropriate, I select “abstrations” for things like Gnome, DNS, fonts, tmp dir usage, etc. When a whole directory tree should be allowed, I double-glob the path (/usr/share/evince/**). Once all the items from the log have been processed, the profile is saved.
  • Finally, I enable the profile with aa-enforce evince. Any disallowed actions will show up in the kernel logs.

Check out the resulting profile for evince.

Now if I end up reading a malicious PDF that takes advantage of some currently-unknown vulnerability in evince, it will be confined to the above AppArmor profile, unable to exec new processes, and only able to write to the Gnome preferences for evince. (It’s also unable to read files out of /home, so that the above profile may be way too strict for common usage. And to even get caught by AppArmor, the imaginary exploit would have to avoid the randomized stack, randomized heap, stack protector, and, since I’m running 64bit, the NX processor bit.)

Be aware, this is still a new bit of packaging for Ubuntu, so you may run into sneaky gotchas. If that happens, please open a bug.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

Powered by WordPress