apparmor broken after reboot on i386
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
klibc (Ubuntu) |
Fix Released
|
Medium
|
Kees Cook |
Bug Description
Binary package hint: apparmor
This problem was witnessed in two separate hardy/386 virtual machines in kvm with the -386, -generic and -server kernels on the guest. This goes back to -7-386 at least (other kernel flavors were tested only with -12). Host OS is amd64 on up to date hardy. Up to date hardy/amd64 guest (only -12-server kernel was tested) appears to work fine.
** Details **
After rebooting with profiles in enforcing mode, apparmor is broken in that it enforces things that it shouldn't. With this entry in the profile:
/var/lib/ldap/* rw,
On boot, slapd fails to start with this in kern.log:
Mar 14 11:56:16 hardy-386 kernel: [ 32.034060] audit(120549577
But if I login and do '/etc/init.d/slapd start', then slapd starts without errors or apparmor messages.
aa-status after boot, but before running '/etc/init.d/slapd start' after logging in:
$ sudo aa-status
[sudo] password for james:
apparmor module is loaded.
2 profiles are loaded.
2 profiles are in enforce mode.
/usr/sbin/slapd
/usr/sbin/named
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
/usr/sbin/named (3932)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
aa-status after boot and after running '/etc/init.d/slapd start' after logging in:
$ sudo aa-status
apparmor module is loaded.
2 profiles are loaded.
2 profiles are in enforce mode.
/usr/sbin/slapd
/usr/sbin/named
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode :
/usr/sbin/named (3932)
/usr/sbin/slapd (4101)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
** Steps to reproduce **
1. Boot an up to date hardy on i386
2. apt-get install slapd
3. reboot (slapd does not start with above error)
4. /etc/init.d/slapd start (this time it works and no errors)
slapd has now been upgraded to have a modified profile that will work around this difference. I am not sure if this is actually a bug, but rather simply a difference in apparmor on different architectures.