AppArmor @Debconf15

In August I went to my first DebConf in Heidelberg/Germany and was happy to meet in person with some of the team mates and one of the upstream developers and maintainers of AppArmor in OpenSuSE, Christian Boltz. Christian presented AppArmor’s inner functioning to the Debian community:

After his talk some of us discussed the long imagined and longed for cross-distro repository for AppArmor profiles. Now that Launchpad supports Git, not only Bazaar, this repository shall help at least Ubuntu, Debian and OpenSuSE share profiles and mutually profit from updates. For now, the discussion about how to organize such a repository still lives on Debian’s gobby, but will certainly be sent to Ubuntu and upstream developers to be improved and approved.

During DebConf, several people encouraged me to apply to Debian’s New Maintainer queue and I’ve decided to so – as soon as I’ve accomplished a little bit more work on my open WNPP bugs (those are new packages which I’ve the intention to get into Debian).

 

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.

Progress

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.

Organization

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!

Future

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.

Thanks

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, planet.debian.org 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.
 /usr/bin/evince
 /usr/bin/evince-previewer
 /usr/bin/evince-previewer//sanitized_helper
 /usr/bin/evince-thumbnailer
 /usr/bin/evince-thumbnailer//sanitized_helper
 /usr/bin/evince//sanitized_helper
 /usr/bin/irssi
 /usr/bin/pidgin
 /usr/bin/pidgin//launchpad_integration
 /usr/bin/pidgin//sanitized_helper
 /usr/bin/tlsdate
 /usr/bin/tlsdate-helper
 /usr/bin/torbrowser-launcher
 /usr/bin/totem
 /usr/bin/totem-audio-preview
 /usr/bin/totem-video-thumbnailer
 /usr/lib/cups/backend/cups-pdf
 /usr/lib/libvirt/virt-aa-helper
 /usr/sbin/apt-cacher-ng
 /usr/sbin/cups-browsed
 /usr/sbin/cupsd
 /usr/sbin/cupsd//third_party
 /usr/sbin/libvirtd
 /usr/sbin/ntpd
 /usr/sbin/tcpdump
 /usr/sbin/tlsdated
 gst_plugin_scanner
 system_tor
0 profiles are in complain mode.
8 processes have profiles defined.
8 processes are in enforce mode.
 /usr/bin/pidgin
 /usr/bin/torbrowser-launcher
 /usr/sbin/cups-browsed 
 /usr/sbin/cupsd
 /usr/sbin/libvirtd
 system_tor
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!

 

Debian will participate in the next round of Outreachy

I am happy to know that this round of OPW internships in Debian can already be considered a success, and that Debian will participate in round 10! More sponsors are welcome to fund more internships.

 

Querying Debian’s Ultimate Database for new usertags

Debian has this great thing called the Ultimate Debian Database, UDD.

As I described in my previous post, Debian’s Bug Tracking System is package centric. Only package maintainers get informed if, for a package they maintain, a bug is opened or commented on. There are no email notifications if a bug is tagged with a keyword though (“usertagged”).

But UDD’s documentation is great! One can simply read the database scheme and then write all sorts of scripts to access the data in this database. That is what I did during the last days. I had a lot of fun finally applying what I learned at one of Coursera’s Python courses. Still, my coding style needs a lot of improvements, and the mentors are heavily reviewing the code 🙂 I am happy about this as sometimes things simply work and then one does not care enough to improve them even more.

Anyhow, now, everytime a bug is tagged for the AppArmor Packaging Team, the team mailing list receives an email. Yay.

To make this happen, a cronjob runs on Alioth every day and checks for added and deleted tags.

 

User Stories and user tags

User Stories

In order to organize the AppArmor documentation on Debian’s wiki, we created some basic User Stories. A User Story is a written in everyday language and supposed to frame in a short and precise way what a user of a software or a reader needs to do, know or find.

The User Stories for this particular documentation were not only written in order to structure the pages into a goal-oriented system rather than into a collection of different technical realms, but we also needed them in order to invent a set of tags. These tags should make it easier for the people who maintain AppArmor related packages in Debian to keep track of bugs related to AppArmor.

The Debian Bug Tracking System is very powerful, but it’s hard to learn to use it in first place, as much of the interaction with it is email based. Furthermore is this bug tracking system package-centric. This means that one can report bugs only against packages. Only the maintainers of a package will be automatically made aware if somebody reported a bug against theirs.

But in an operating system packages interact with, depend on or can break each other. When a software ships an AppArmor profile for example, and a recent version of this profile has not been well tested, it could break the program’s functionality and lead to a bug report.
As the AppArmor Packaging Team aims at providing help to package maintainers who ship such profiles, as well as to other contributors who want to request that such profiles are updated or patched, for example, they’d like to be aware of such bugs which concern AppArmor but are reported against other packages.

User Tags

There is a functionality called user tag in Debian’s BTS. A user tag is a keyword which can be set for a particular user on a bug. It’s possible to add single or multiple tags and also to delete them, once they have become obsolete.

user tag also needs a user for whom the tag is relevant. The user corresponds to an email address. In our case, that’s the Debian mailing list for the AppArmor Packaging Team.

Here is a list of user tags we defined and detailed instructions on how to set these tags. And here is a list of all bugs which have already been tagged with keywords for the Debian AppArmor Packaging Team.

Next step

Unfortunately, Debian’s BTS does not – yet – provide a means to receive a notification everytime a bug is usertagged. That is why I needed to report a so called wishlist bug against the bugs.debian.org package (it’s not really a package, but simply a pseudo package so one can report bugs against it).

In the meantime, I will need to query the Debian’s Ultimate Database (UDD) in order to receive these notifications.

 

Tracking AppArmor related bugs in Debian

For newcomers, it’s quite hard to understand where to request or submit bugs, patches, modifications for Debian packages.This post shall hilight a little bit how the Debian Bug Tracking System works, and how we track AppArmor related bugs there.

In Debian, nearly everything is documented somewhere. One simply needs to find the information.

Package tracker

On the Debian package tracking system, one can always find links to the corresponding Git repository for a package as well as links to the bugs affecting a package, see for example the apparmor-profiles-extra package page (Git, bugs). This package contains various AppArmor profiles which have not yet been included within the software package they are supposed to confine.

Bug tracker

The Debian Bug Tracking System (BTS) is package-centric. That means, that you can file bugs only against a package. There are also pseudo-packages, like wnpp. wnpp stands for “work needing and prospective packages”. This is where people file RFP (Request For Packaging) and ITP (Intent To Package) bugs.

How does one file a bug?

The Debian BTS is email based. That means, that you need to file or reply to bugs using an email client.

There is a great interactive tool, which can be used either from the command line: reportbug or from the graphical interface. reportbug will guide you through the process of sending a bug to the BTS, while formatting your bug report correctly and providing some information about your operating system and versions of installed packages.

How can we track bugs related to AppArmor?

How can we track bugs in packages which might be related to AppArmor, for example, due to a buggy AppAmor profile?

As already mentioned on this blog, there is a great feature on that BTS. It’s called a usertag. Basically, usertagging a bug means, to add a user’s email address and a specific tag to a bug number. Like that, one can mark a bug, for example in the auditd package, which thus becomes visible to the Debian AppArmor Team.

The only problem with usertags is that one should define them first, in order to be able to keep track.

Usertags

We defined some usertags together, which rely on our User Story scenarios.

You can find all tags and their descriptions in our documentation: how to report a bug involving AppArmor in Debian?

 

Updating a profile in Debian’s apparmor-profiles-extra package

I have gotten my first patch to the Pidgin AppArmor profile accepted upstream. One of my mentors thus suggested that I’d patch the updated profile in the Debian package myself. This is fairly easy and requires simply that one knows how to use Git.

If you want to get write access to the apparmor-profiles-extra package in Debian, you first need to request access to the Collaborative Maintenance Alioth project, collab-maint in short. This also requires setting up an account on Alioth.

Once all is set up, one can export the apparmor-profiles-extra Git repository.
If you simply want to submit a patch, it’s sufficient to clone this repository anonymously.
Otherwise, one should use the “–auth” parameter with “debcheckout”. The “debcheckout” command is part of the “devscripts” package:

debcheckout --auth apparmor-profiles-extra

Go into the apparmor-profiles-extra folder and create a new working branch:

git branch workingtitle
git checkout workingtitle

Get the latest version of profiles from upstream. In “profiles”, one can edit the profiles.

Test.

The debian/README.Debian file should be edited: add what relevant changes one just imported from upstream.

Then, one could either push the branch to collab-maint:

git commit -a
git push origin workingtitle

or simply submit a patch to the Debian Bug Tracking System against the apparmor-profiles-extra package.

The Debian AppArmor packaging team mailing list will receive a notification of this commit. This way, commits can be peer reviewed and merged by the team.

 

How is the Outreach Program going so far?

During the last internship meeting with my mentors, they suggested as a final meeting topic “Feedback on mentoring”.  I found that really useful. It’s a great idea to provide a space to talk about the human part and social interactions. Thanks!

One mentor said:

I’ve been doing mentoring for years. A couple GSoCs, a NM process, etc. And I have to say that it’s probably the first time that I have the clear feeling that I’m spending way less time mentoring, than I would spent doing the work myself.

It also feels comforting to read the blog posts of my co-interns, especially While getting things not done by Anke who works as an intern with Wikimedia.

While understanding and writing the AppArmor documentation for Debian, I realize how high the barriers to contribute to Free Software actually are: one needs to read a lot of documentation, learn many different tools, but also have social interactions with package maintainers and upstream / source code developers, request access and logins to various websites and repositories.
It’s not easy to make the first step. But once you’ve done it, you can make a second one, and then slowly learn how to run.

 

How to contribute to the AppArmor upstream profiles

If you want to contribute to existing/upstream AppArmor profiles, you need to create an account on Canonical’s launchpad and to upload a SSH key to be able to push your changes. You will also need to install Canonical’s version control system, called Bazaar:

apt-get install bzr

Go to or create a repository where you want to checkout the modifications:

mkdir apparmor-dev
cd apparmor-dev
bzr branch lp:apparmor-profiles master
ls master

Define your identity like this:

bzr whoami "My Name <my@email.com>"

Bazaar does not handle branches like Git does, unfortunately. It is a little bit weird in first place that you will need to create a directory where you would create a copy of the master branch. You would then work on this branch and later ask for a merge into the master branch.

mkdir myname
bzr branch master myname/pidgin
ls myname/pidgin

Then, start modifying the profiles using a text editor and test them. Testing is done through dis/enabling the profile.
Once done, you can commit and push the changes to your distant repository:

bzr ci
bzr push

Then, you need to connect to Launchpad’s web interface. Go to your page, and look for the branch you just pushed. Click on “change branch details” and link the branch to apparmor-profiles. Then you will be able to request a merge through the webinterface.

Note that upstream AppArmor profiles also live in other repositories.