Comment 9 for bug 578922

SRU Justification (apparmor)

1. impact of the bug is medium for stable releases. While no applications shipped in Ubuntu are directly affected by this, it would be good if our LTS release provided a more secure user-tmp abstraction for people deploying new profiles on Ubuntu 10.04 LTS.

2. This has been addressed during the maverick development cycle.

3. Patch is small. It places 'owner' in front of /tmp/** and /var/tmp/** as well as requiring 'owner' for @{HOME}/tmp/ and its files and subdirectories.

4. TEST CASE:
$ cp /usr/share/example-content/Kubuntu_leaflet.jpg /tmp
$ sudo chown root:root /tmp/Kubuntu_leaflet.jpg
$ sudo aa-enforce /etc/apparmor.d/usr.bin.firefox
$ firefox /tmp/Kubuntu_leaflet.jpg

At this point, firefox will not display the image and something like the following should be in dmesg:
[ 1298.220693] type=1503 audit(1288797298.697:138): operation="open" pid=2948 parent=2944 profile="/usr/lib/firefox-3.6.12/firefox-*bin" requested_mask="::r" denied_mask="::r" fsuid=1000 ouid=0 name="/tmp/Kubuntu_leaflet.jpg"

5. This will regress if a confined application tries to access files owned by another user in /tmp (indeed, that is the protection we want ;) and when someone confines two different applications that a) run under differing user ids and b) interact with each other by one writing to /tmp and the other reading that file from /tmp. I imagine that there are very few users who would be affected by this. On the desktop, the evince profile is affected at all by this change because it explicitly allows read access to any files with an extension that it has support for. Firefox's profile is disabled by default.

This is a change requiring the most testing and thought. I maintain it is an important proactive fix for Lucid. It has been in maverick for several months with no reported regressions once we decided on the right approach. Once in -proposed, I plan to run the QRT tests on all AppArmor confined applications in Lucid to verify no regressions.