apparmor doesn't respect ignore directory on boot

Bug #496770 reported by Tessa
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: apparmor

This appears new to karmic, and I'm seeing it on the x86 port. On boot, profiles symlinked into the ignore directories don't get ignored, they get set to complain mode. A "service apparmor reload" or "service apparmor restart" doesn't set them to ignore properly, you need to do a full "service apparmor stop && service apparmor start" to get it to properly ignore the rules.

I see this consistently with the enforcement rules on Dovecot, as my maildirs are in ~/mail for each user, and this throws a lot of errors in syslog with the default apparmor ruleset.

aa-status on boot shows:

apparmor module is loaded.
22 profiles are loaded.
10 profiles are in enforce mode.
   /usr/sbin/clamd
   /usr/bin/freshclam
   /usr/sbin/cupsd
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/sbin/avahi-daemon
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/tcpdump
   /usr/lib/cups/backend/cups-pdf
   /usr/sbin/mysqld
   /sbin/dhclient3
12 profiles are in complain mode.
   /usr/sbin/traceroute
   /bin/ping
   /usr/sbin/mdnsd
   /usr/sbin/ntpd
   /usr/sbin/identd
   /sbin/klogd
   /usr/sbin/nmbd
   /usr/sbin/dnsmasq
   /sbin/syslogd
   /sbin/syslog-ng
   /usr/sbin/nscd
   /usr/sbin/dovecot
15 processes have profiles defined.
6 processes are in enforce mode :
   /usr/sbin/avahi-daemon (1163)
   /usr/sbin/cupsd (3094)
   /usr/sbin/mysqld (2652)
   /usr/sbin/clamd (2048)
   /usr/sbin/avahi-daemon (1164)
   /usr/bin/freshclam (2146)
9 processes are in complain mode.
   /usr/sbin/dovecot (3015)
   /usr/sbin/dovecot (3007)
   /usr/sbin/dovecot (3005)
   /usr/sbin/nmbd (2852)
   /usr/sbin/dovecot (3685)
   /usr/sbin/dovecot (3672)
   /usr/sbin/ntpd (1067)
   /usr/sbin/dovecot (3093)
   /usr/sbin/dovecot (3671)
0 processes are unconfined but have a profile defined.

This is the same after a service reload and a service restart. After a full service stop/start cycle, it shows:

apparmor module is loaded.
22 profiles are loaded.
10 profiles are in enforce mode.
   /usr/sbin/clamd
   /usr/bin/freshclam
   /usr/sbin/cupsd
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/sbin/avahi-daemon
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/tcpdump
   /usr/lib/cups/backend/cups-pdf
   /usr/sbin/mysqld
   /sbin/dhclient3
12 profiles are in complain mode.
   /usr/sbin/traceroute
   /bin/ping
   /usr/sbin/mdnsd
   /usr/sbin/ntpd
   /usr/sbin/identd
   /sbin/klogd
   /usr/sbin/nmbd
   /usr/sbin/dnsmasq
   /sbin/syslogd
   /sbin/syslog-ng
   /usr/sbin/nscd
   /usr/sbin/dovecot
9 processes have profiles defined.
0 processes are in enforce mode :
0 processes are in complain mode.
9 processes are unconfined but have a profile defined.
   /usr/sbin/cupsd (3094)
   /usr/sbin/mysqld (2652)
   /usr/sbin/clamd (2048)
   /usr/sbin/dovecot (3005)
   /usr/sbin/avahi-daemon (1163)
   /usr/sbin/nmbd (2852)
   /usr/sbin/ntpd (1067)
   /usr/sbin/avahi-daemon (1164)
   /usr/bin/freshclam (2146)

My config has all the dovecot profiles symlinked into the "ignore" directory, of course.

ProblemType: Bug
Architecture: i386
Date: Mon Dec 14 15:18:41 2009
DistroRelease: Ubuntu 9.10
Package: apparmor 2.3.1+1403-0ubuntu27.2 [modified: sbin/apparmor_parser]
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic-pae
SourcePackage: apparmor
Uname: Linux 2.6.31-16-generic-pae i686

Revision history for this message
Tessa (unit3) wrote :
Revision history for this message
Tessa (unit3) wrote :

Erm, that should be "disable" directory, rather than "ignore". Just to get the terminology straight.

Revision history for this message
Tessa (unit3) wrote :

Also of some concern is how, after the full apparmor restart, it lists a bunch of processes unrelated to dovecot as being "unconfined". I'm not up on apparmor terminology, but that makes it seem like it's no longer enforcing those processes.

Revision history for this message
Kees Cook (kees) wrote :

I think this has been fixed, possibly as early as karmic. If you're still seeing the problem on Lucid, please open a new bug. Thanks!

Changed in apparmor (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.