apparmor broken after reboot on i386

[Jamie Strandboge]

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(1205495776.396:2): operation="file_mmap" request_mask="mrw::" denied_mask="m::" name="/var/lib/ldap/__db.001" pid=3745 profile="/usr/sbin/slapd" namespace="default"

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)

[Jamie Strandboge (jdstrand)]

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.

[LaMont Jones (lamont)]

With cupsys 1.3.6-3ubuntu1 and apparmor 2.1+1075-0ubuntu6 on i386 with 2.6.24-12-generic (not a vm) I see:

Apr 2 08:01:45 mix kernel: [37412.733502] audit(1207144905.051:17): operation="file_mmap" request_mask="mr::" denied_mask="m::" name="/var/lib/misc/group.db" pid=7152 profile="/usr/sbin/cupsd" namespace="default"

lamont

[John Johansen (jjohansen)]

This is a side effect of linux personalities. When booting on an ia32 machine hardy has the READ_IMPLIES_EXEC flag set in its personality. This causes an mmap for read permission to also ask for PROT_EXEC, which causes the extra 'm' request seen above. Ubuntu by default is mounting several things as nosuid which has the side effect of clearing the READ_IMPLIES_EXEC flag when a user logs in. This flag stays cleared even when the user sudo's, so starting the service from sudo is not asking for the extra 'm' permission.

If you enable the root account and log directly into root and try to start the given services, you will see the same reject as at boot.

There are several way to fix this:
- just stick the 'm' permission in the AppArmor profiles. This is pretty much required for ia32 machines
  that don't support noexec in the mmu
- set the personality at boot so that READ_IMPLIES_EXEC is cleared.
- don't use the nosuid mount option

[John Johansen (jjohansen)]

sorry, I jumped the gun slightly and mis read a mount line and a piece of code. The nosuid option does interact with this but is not whats causing the clearing of the personality. Execution of any setuid binary will cause the personality to get cleared, so using either su or sudo to switch from user to root clears the personality.

The net effect is no different however in that on boot READ_IMPLIES_EXEC is set, so apparmor is being asked for the extra 'm' permission. The best solution at the moment if you want a single policy set for all x86 machines is to just include the 'm' permission.

[Kees Cook (kees)]

This is close, but not full, solution to the problem. For reasons currently unknown, the final shared link still gains "E" in GNU_STACK.

[Kees Cook (kees)]

klibc's run-init has GNU_STACK with "E", so READ_IMPLIES_EXEC is passed down to upstart and children.

[Launchpad Janitor (janitor)]

This bug was fixed in the package klibc - 1.5.7-4ubuntu2

---------------
klibc (1.5.7-4ubuntu2) hardy; urgency=low

  * Add 30-drop-executable-stack.patch: do not generate executable
    stack for ia32, so the READ_IMPLIES_EXEC does not get set for
    children (LP: #202161).

 -- Kees Cook <email address hidden> Thu, 03 Apr 2008 11:37:28 -0700