jaunty: Apparmor doesn't parse logs and doesnt generally work.

[thosjo]

The apparmor packages in Jaunty cant be stopped, started or restarted properly.
They can't generate new rules or load previously installed ones either.

Attached is a log (sort of) of the incorrect behavior of apparmor in Jaunty.
Also attached is a reference log from 8.04.

[thosjo (thomas-sjogren)]

Intrepid apparmor behavior

[Timo Aaltonen (tjaalton)]

Confirming. Rebooting helped though, but it's not a solution.

[Johan Ryberg (jryberg)]

Confirming on Jaunty. Does not parse but the logs contains entries that should been read by aa-logprof

[thosjo (thomas-sjogren)]

Rebooting didn't help sorry to say.

Also found that the apparmor_parser doesn't handle some of the flags, --Complain and -d seen below, mentioned in the help text.

thosjo@thosjo-lab:~$ uptime && sudo aa-complain /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
 12:19:46 up 6 min, 2 users, load average: 1.15, 0.77, 0.36
Setting /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh to complain mode.
/sbin/apparmor_parser: Unable to replace "/usr/lib/firefox-3.0.7/firefox.sh". Unknown error

thosjo@thosjo-lab:~$ sudo apparmor_parser --Complain /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
apparmor_parser: unrecognized option '--Complain'
Novell/SUSE AppArmor parser version 2.3
Copyright (C) 1999, 2000, 2003, 2004, 2005, 2006 Novell Inc.

Usage: apparmor_parser [options] [profile]

Options:
--------
-a, --add Add apparmor definitions [default]
-r, --replace Replace apparmor definitions
-R, --remove Remove apparmor definitions
-C, --Complain Force the profile into complain mode
-B, --binary Input is precompiled profile
-p, --preprocess Dump profiles with includes expanded
-N, --names Dump names of profiles in input.
-S, --stdout Dump compiled profile to stdout
-b n, --base n Set base dir and cwd
-I n, --Include n Add n to the search path
-f n, --subdomainfs n Set location of apparmor filesystem
-m n, --match-string n Use only match features n
-n n, --namespace n Set Namespace for the profile
-q, --quiet Don't emit warnings
-v, --version Display version info and exit
-d, --debug Debug apparmor definitions
-h, --help Display this text and exit
thosjo@thosjo-lab:~$ sudo apparmor_parser -C /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
apparmor_parser: Unable to add "/usr/lib/firefox-3.0.7/firefox.sh". Unknown error
thosjo@thosjo-lab:~$ sudo apparmor_parser -d -C /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
thosjo@thosjo-lab:~$
thosjo@thosjo-lab:~$ sudo apparmor_parser -dC /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
thosjo@thosjo-lab:~$ sudo apparmor_parser -d /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
thosjo@thosjo-lab:~$ sudo aa-complain /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh
Setting /etc/apparmor.d/usr.lib.firefox-3.0.7.firefox.sh to complain mode.
/sbin/apparmor_parser: Unable to replace "/usr/lib/firefox-3.0.7/firefox.sh". Unknown error

thosjo@thosjo-lab:~$

[Jamie Strandboge (jdstrand)]

The aa-logprof/aa-genprof issue is almost certainly bug #340183.

[Jamie Strandboge (jdstrand)]

Thomas, can you try to determine if it is a specific profile that is causing apparmor to fail? Your firefox one may be a good start. just remove them one by one from the /etc/apparmor.d directory and see if apparmor will start and stop correctly. If you find the offending profile, please post it. Please respond either way, thanks.

[Steve Beattie (sbeattie)]

Thanks to Timo's help on irc, we were able to debug this a little further.

The parser, when loading the policies, fails with the following strace:

  open("/sys/kernel/security/apparmor/.load", O_WRONLY) = 3
  write(3, "\4\10\0version\0\2\5\0\0\0\4\10\0profile\0\7\5\22\0/u"..., 31321) = -1 EACCES (Permission denied)

The only reason I see for the write to return this, in looking at the apparmorfs.c code, is due to the calling process being confined, either in complain or enforce mode (the parser was definitely running as root, the open() succeeded and the parser aborts early if it's not). Timo confirmed this was the case with
'cat /proc/self/attr/current' returning 'null-complain-profile' instead of the expected 'unconfined'.

(The null-complain-profile is normally attached to processes that are exec()ed from processes in complain mode, as the kernel code doesn't know whether the admin will choose to make a separate policy or roll it in to calling process' profile.)

One of the policies Timo was working on was one for sshd (and he confirmed that he was reloading policy over ssh); however, I'm unable to reproduce the behavior by taking the sshd profile shipped in the apparmor-profiles package and putting it in complain mode; the resulting shell is still listed as unconfined. I also note that the original reporter's information indicated no profile for sshd.

There have been bugs in the past with apparmor mistakenly applying the null-complain-profile in situations where it shouldn't; it's possible that that is what's happening here.

> Also found that the apparmor_parser doesn't handle some of the flags,
> --Complain and -d seen below, mentioned in the help text.

Dur. --complain got mis-documented as having the uppercase C; I've fixed the upstream code to support either. The -d argument is more for apparmor developers, you'll get output if you do -dd, though again I've fixed the upstream code to emit that with only one -d. (It will also emit debugging statements if they've been enabled at compile time, but it's not really well supported.)

[thosjo (thomas-sjogren)]

I removed all policies except dhcp and avahi, and there was no start/stop issues.
Then I added the Firefox policy and the null-complain-profile started to show up.

root@thosjo-lab:/etc/apparmor.d# /etc/init.d/apparmor stop
Unloading AppArmor profiles : done.

root@thosjo-lab:/etc/apparmor.d# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
1 processes have profiles defined.
0 processes are in enforce mode :
1 processes are in complain mode.
   null-complain-profile (6293)
0 processes are unconfined but have a profile defined.

root@thosjo-lab:/etc/apparmor.d# ps ax|grep 6293
 6293 ? Sl 0:21 /usr/lib/firefox-3.0.7/firefox

I think this confused apparmor after an apparmor start, see my comment in the output:

root@thosjo-lab:/etc/apparmor.d# aa-status
apparmor module is loaded.
7 profiles are loaded.
6 profiles are in enforce mode.
   /usr/lib/connman/scripts/dhclient-script
   /sbin/dhclient3
   /usr/sbin/cupsd
   /sbin/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/NetworkManager/nm-dhcp-client.action
1 profiles are in complain mode.
   /usr/lib/firefox-3.0.7/firefox.sh <<<<<<<<<<< Shouldn't this be unconfined?
3 processes have profiles defined.
0 processes are in enforce mode :
1 processes are in complain mode.
   null-complain-profile (6293)
2 processes are unconfined but have a profile defined.
   /sbin/dhclient3 (5861)
   /usr/sbin/cupsd (6242)

All Firefox operations seems to get hooked to the null-complain-profile:

root@thosjo-lab:/etc/apparmor.d# grep firefox-3.0.7 /var/log/messages
Mar 12 12:19:00 thosjo-lab kernel: [ 327.546264] type=1502 audit(1236856740.843:47904): operation="inode_permission" requested_mask="::x" denied_mask="::x" fsuid=1000 name="/usr/lib/firefox-3.0.7/firefox.sh" pid=4394 profile="null-complain-profile"
Mar 12 12:23:14 thosjo-lab kernel: [ 581.181988] type=1502 audit(1236856994.483:58853): operation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=1000 name="/usr/lib/firefox-3.0.7/chrome/classic.jar" pid=5027 profile="null-complain-profile"

[thosjo (thomas-sjogren)]

Firefox policy and logs

[thosjo (thomas-sjogren)]

Removed abstractions and dash from policy and tested again.
No improvement.

[thosjo (thomas-sjogren)]

... and here's some new behavior.
Added all previous policies, Apparmor didn't fail to load them this time but now it didn't unload the policies when stopped instead.

thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor start
Loading AppArmor profiles - AppArmor already loaded with profiles.: Skipped.
thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor start
Loading AppArmor profiles - AppArmor already loaded with profiles.: Skipped.
thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor stop
Unloading AppArmor profiles : done.
thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor stop
Unloading AppArmor profiles : done.
thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor start
Loading AppArmor profiles - AppArmor already loaded with profiles.: Skipped.
thosjo@thosjo-lab:~$ sudo /etc/init.d/apparmor stop
Unloading AppArmor profiles : done.

[Jamie Strandboge (jdstrand)]

Can you try this on Ubuntu 9.10 and see if the problem is fixed? Thanks.

[thosjo (thomas-sjogren)]

The above problem doesn't show up in 9.10.

$ lsb_release -a && sudo dpkg -l |grep apparmor
LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic
ii apparmor 2.3.1+1403-0ubuntu27 User-space parser utility for AppArmor
ii apparmor-utils 2.3.1+1403-0ubuntu27 Utilities for controlling AppArmor
ii libapparmor-perl 2.3.1+1403-0ubuntu27 AppArmor library Perl bindings
ii libapparmor1 2.3.1+1403-0ubuntu27 changehat AppArmor library

[Jamie Strandboge (jdstrand)]

Actually, in looking at the profile more carefully, I think this is bug #400349. See https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/400349/comments/7 for details. If this is in error, please adjust.

[Jamie Strandboge (jdstrand)]

I meant to say, the remaining Jaunty part is bug #400349.

[Jamie Strandboge (jdstrand)]

Marking Jaunty task as 'Invalid' as it is a dupe of #400349.