services started by upstart need to load their AppArmor profile

[Jürgen Kreileder]

Binary package hint: apparmor

[lucid with apparmor 2.5-0ubuntu3]

Apparently apparmor profiles get loaded too late in the boot process to confine all processes that have a profile defined.

Either /etc/init.d/apparmor should be run earlier or the profiles should be loaded by upstart before all those services which start on local-filesystems get started.

I'd rate this problem pretty major, if not even a security problem: It gives users a false impression of security.
Some stock services that have profiles defined are unprotected after boot.
Also, profiles generated by the user might look fine -- but after the next reboot the protection unexpectedly is gone again.

aa-status output after boot:

System 1:
2 processes are unconfined but have a profile defined.
   /usr/sbin/smbd (1082)
   /usr/sbin/smbd (882)

System 2:
6 processes are unconfined but have a profile defined.
   /usr/sbin/mysqld (1015)
   /usr/sbin/nmbd (1169)
   /usr/sbin/nmbd (1162)
   /usr/sbin/rsyslogd (953)
   /usr/sbin/smbd (932)
   /usr/sbin/smbd (1045)

System 3:
5 processes are unconfined but have a profile defined.
   /usr/sbin/mysqld (1193)
   /usr/sbin/rsyslogd (1164)
   /usr/sbin/vsftpd (1163)
   /usr/sbin/vsftpd (1161)
   /usr/sbin/vsftpd (1162)

Manual fix: restart those services after each boot

[Jamie Strandboge (jdstrand)]

Thanks for using Ubuntu and reporting a bug.

This is due to the upstartification of services in Ubuntu 10.04. For the supported profiles, mysql started before apparmor. This is bug #573206 and a fix is available in lucid-proposed (5.1.41-3ubuntu12.1).

For the others, the upstart scripts need to be adjusted accordingly, like in bug #573206. There is some work that is going to be done in Ubuntu 10.10 that should make this easier.

[Simon Déziel (sdeziel)]

This issue is affecting smbd on my system. The attached patch is inspired of http://launchpadlibrarian.net/47035494/mysql-dfsg-5.1_5.1.41-3ubuntu12.1.debdiff The patch fixes the issue completely for me. Could this be part of a SRU ? Should I open a bug against samba instead ?

Thanks,
Simon

[Simon Déziel (sdeziel)]

Here is a reworked patch inspired by https://bugs.launchpad.net/ubuntu/+source/cups/+bug/690040/comments/5

[Jamie Strandboge (jdstrand)]

Simon, I think you want to look at https://bugs.launchpad.net/ubuntu/+source/cups/+bug/690040/comments/10 instead. You want the apparmor loading to happen at the top of the pre-script, otherwise things like running smbd in inetd will cause the apparmor profile to not load.

[Simon Déziel (sdeziel)]

@Jamie,

Thank you for the hint, it makes a lot of sense. Let me know if I should open a bug against samba and create a debdiff with the attached fix.

[Kees Cook (kees)]

Now that the apparmor helper exists, this can actually be simplified down to a single line in the pre-start:

pre-start script
    /lib/init/apparmor-profile-load usr.sbin.smbd
end script

The real problem is that there isn't a way to easily solve this in the general case with Upstart. There is not common convention that .conf files are named after the daemon names, etc. So, instead, each of these services needs to carry the profile-load line, even when no profile is shipped with the service.

[Jamie Strandboge (jdstrand)]

Based on Kees' comment, I am marking this "Won't Fix" for now as there is currently no way for upstart to know what profile to load without declaring the profile in some way. Will re-open if this changes.

[Ralf Spenneberg (ralq)]

This is still unsolved for 12.04. Please reopen the bug.

The proposed fixes do not work. They modify the start scripts of the specific daemons to load only their profiles. Any security oriented admin creating his own profiles for additional services not yet protected by ubuntu profiles is having the same problem.

Only reasonable fix: AppArmor needs to be loaded first.

[Jamie Strandboge (jdstrand)]

This won't be fixed in Ubuntu this cycle (see https://lists.ubuntu.com/archives/upstart-devel/2011-December/001771.html for details). That said, we will be updating the documentation, which we should have done a long time ago (see bug #974089).