Bug#661151: [apparmor] Bug#661151: linux-2.6: lacks AppArmor kernel/userspace interface

[intrigeri <intrigeri@boum.org>]

intrigeri wrote (31 May 2012 13:14:13 GMT) :
>> Looking back over the bug log, I see that wasn't requested, so I'm
>> only applying 'AppArmor: compatibility patch for v5 interface' now.

Unfortunately, the resulting kernel (linux-image-3.2.0-2-amd64
3.2.19-1), combined with the AppArmor userspace tools currently in sid
(2.7.103-2), displays worse behaviour than the previous one.

Loading a profile shipped with apparmor-profiles fails:

  $ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.avahi-daemon
  apparmor_parser: Unable to replace "/usr/sbin/avahi-daemon".  Profile doesn't conform to protocol
  zsh: exit 234   sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.avahi-daemon

... as a result, usr.sbin.avahi-daemon does not show up in the
cache directory.

Another one fails differently:

  $ sudo apparmor_parser -r /etc/apparmor.d/usr.bin.chromium-browser 
  zsh: exit 185   sudo apparmor_parser -r /etc/apparmor.d/usr.bin.chromium-browser

... but is cached nevertheless:

  $ ls -l /etc/apparmor.d/cache/usr.bin.chromium-browser
  -rw------- 1 root root 251K juin   2 18:59 /etc/apparmor.d/cache/usr.bin.chromium-browser

Kernel log excerpt for this last attempt:

  type=1400 audit(1338678658.161:166): apparmor="STATUS" info="failed
  to unpack profile" error=-71 pid=21836 comm="apparmor_parser"
  name="/usr/lib/chromium-browser/chromium-browser" offset=171
  type=1400 audit(1338678658.161:167): apparmor="STATUS"
  operation="profile_replace" pid=21836 comm="apparmor_parser"
  audit(1338678658.165:168): apparmor="STATUS" info="failed to unpack
  profile" error=-71 pid=21836 comm="apparmor_parser"
  name="/usr/lib/chromium-browser/chromium-browser//browser_java"
  offset=166 type=1400 audit(1338678658.165:169): apparmor="STATUS"
  operation="profile_replace" pid=21836 comm="apparmor_parser"

In any case, neither the profiles that end up cached not the ones that
seemingly fail to load earlier are applied to processes. So, this is
a regression against the previous state of AppArmor support in Debian.

I'm unsure the kernel is at fault / the place where something must
be improved.

John, Kees, may you please check why the patch that was applied to
this Debian kernel could possibly expose such a bug?

I've seen similar old issues on Launchpad (e.g. LP#968956), but most
don't apply to the version of the userspace tools we ship in sid.