Final report from the Outreach Program round 9

Between december 9th 2014 and march 9th 2015 I’ve been working as an intern for Debian on Improving AppArmor support in Debian.


Before the internship started, I had no clue about AppArmor at all. Reading the Wikipedia page and the AppArmor wiki did barely enlighten me. At least, until I got my hands dirty and installed and activated it. I was able to do this only because there was already some basic documentation on the Debian wiki on how to get AppArmor running on a Debian system.

When the internship started I felt a little bit lost. I started to read the documentation and to play around with some AppArmor profiles. But the error messages I saw and the profiles I opened for reading overwhelmed me. What did all these lines mean?

Then one mentor briefed me about the current status of AppArmor in Debian. I took many notes and tried to bring some order into the information I was being given. These notes became the first page of the documentation and my first blog post.
Surprise: suddenly I was in the middle of knowing what we were talking about and how the next few weeks would look like.

To start with, I have set up a test environment and continued to test some of the profiles which came with the packages I had installed, namely apparmor-profiles-extra which provided me with a profile for Pidgin. I was very much interested in securing this several thousand lines long C-code application on my machine! As a Pidgin user, I noticed immediately that one of my favourite features – pidgin blinklight – threw an error in the logs. I tried to fix it on my test VM and eventually made it work.

Now knowing that such fixes should first be done upstream, i cloned the corresponding upstream repository and sent my first patch. It was not easy at first to switch to another VCS than Git, although I had been using Bazaar and Subversion years ago.

Shortly afterwards, I saw my patch showing up on the upstream mailing list, and some days later it got merged. That was a huge encouragement.

I was now able to write more documentation on how to contribute upstream.

In order to organize the documentation, we’ve set up some User Stories. I did not know about this tool before and had quite a hard time to grasp all the details but it proved to be very useful as some pages started to become long and confusing.

Writing the documentation took up a lot of time, but before being able to write anything down, I needed to work everything out! This way I incidentally learned how to interact with many parts of Debian’s infrastructure:

  • Git repositories for packaging – I imported my upstream patches into the AppArmor team’s repositories. My previous experience in Debian packaging was not only helpful but indispensable for this task.
  • Debian bug tracker – I learned more about reporting and usertagging bugs and filed some whishlist bugs which would make life easier.
  • Debian wiki – I wrote documentation but I also read a lot of documentation, namely about using the Bug Tracking System and making things work on Alioth.
  • Ultimate Debian Database – I wrote a Python script which queries the UDD and sends email notifications for new usertags. Writing the Python script was a lot of fun. I had some prior coding experience, but thanks to the mentors’ and upstream authors’ feedback I realized how important it is to write consistent code that can be easily understood and maintained by several people.
  • Setting up Git repositories, post commit hooks and cronjobs on Alioth for group maintaining scripts.

While playing around with the tools provided to inspect AppArmor status on the system, I even accidentally found a little bug in one of the upstream tools. It got fixed very quickly after I mentioned it on the AppArmor team’s mailing list.


Although I was uncomfortable with this in the beginning, we organized public meetings every two weeks on IRC. These meetings were also attended by MeetBot who took care of taking notes and leaving a trace of our discussions.
Based on the meetings, I maintained a progress page and todo list on the Debian wiki, which helped us to know which tasks were planned for the next two weeks. Before each meeting I sent a status update to the mailing list, so the mentors could catch up with my work.

During the meetings I was not only asked to provide feedback on progress but also on mentoring itself. It proved to be very useful to be able to say where I was stuck and if the mentoring process worked out well enough (it did!).
Furthermore, I got regular, detailed and pedantic (thanks for trying to push me to perfection!) feedback on the team’s mailing list.

The mentors had introduced me on the upstream IRC channel in the beginning, so most of the people who are active there knew about my existence, something which also proved to be handy!


The internship time is over, but some work remains to be done. As a new member of the AppArmor Packaging team, I am committed to make it happen:

  • Think about a cross distro meeting – there was a proposal to do that during DebConf
  • Write the migrate profile documentation after migrating a profile in a real world scenario together with intrigeri.
  • Fix Debian bug #702030 – intrigeri should review my technical proposal before I work on it.


I feel much more confident after these three months, technically but also personally.

Thank you: Holger Levsen and intrigeri for mentoring and encouraging me on this journey and to upstream contributors Christian Boltz, Steve Beattie (and everybody else I might forget here) for providing help and feedback.

The Debian community (OPW organizers, sponsors, Alioth maintainers, maintainers and others) has been very friendly and welcoming and I am very happy to be part of it.


So, how usable is AppArmor in Debian?

The short answer is: using AppArmor in Debian is fairly straight forward.

Installing and activating it though is not – yet – a very user friendly experience. One needs to install the apparmor package, then activate it in the kernel by editing a line in the GRUB bootloader and then reboot. The procedure is explained in detail here.
We are working on fixing Debian Bug #702030 which aims at making the installation process easier for normal users by activating the module automatically as soon as one installs the apparmor package.

Once you have set this up though, you’re good to go. Profiles for confining processes and programs should then be activated automatically.

One can verify this through the `sudo aa-status` command which should output something like this:

apparmor module is loaded.
30 profiles are loaded.
30 profiles are in enforce mode.
0 profiles are in complain mode.
8 processes have profiles defined.
8 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

As of today there are only a dozen packages which ship their own profile in Debian: bind9, clamav, cups-browsed & cups-daemon,  libvirt-daemon-system, mysql-5.5, lightdm, obfsproxy, sssd, tlsdate, tor, torbrowser-launcher, vidalia.

In order to confine other applications, like evince, irssi, ntpd, pidgin, totem or tcpdump, one can install the apparmor-profiles-extra package.

All those profiles work very well in a Debian Wheezy environment or higher, from my own experience. (Only the torbrowser-launcher profile needs to be fixed in wheezy-backports, but works well in Jessie or higher – I’m working on it.)

If you want to confine other applications and found a profile which you want to use on your system, you can copy that profile into /etc/apparmor.d/ and then run

aa-enforce /etc/apparmor.d/myprofile

And that’s pretty much it!