pam_apparmor fails to hunt through the hats
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Fix Released
|
Medium
|
Unassigned | ||
2.5 |
Fix Released
|
Medium
|
Unassigned | ||
apparmor (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Lucid |
Fix Released
|
Medium
|
Unassigned |
Bug Description
SRU Justification
1. impact of the bug is medium for stable releases and very much limits the utility of pam_apparmor, but the fix is non-intrusive. It is included here as part of the 2.5.1 update for Lucid (LP: #660077)
2. This has been fixed in natty.
3. Patch simply adjusts changehat/
4. TEST CASE: run the AppArmorPAM tests in lp:qa-regression-testing/scripts/test-apparmor.py. Several tests fail with the version in Lucid and all are fixed in the 2.5.1 upload.
5. The regression potential is very low for this patch as it only adds a single ENOENT check, libpam-apparmor is in universe and it is not widely used yet. Getting this fixed would be an important step in getting pam-apparmor more widely used since LTS users are more likely to require the extra security features provided by libpam-apparmor.
Binary package hint: apparmor
I have pam_apparmor set up for sshd as follows.
session optional pam_apparmor.so order=user,
It never searches group or default. It thinks it finds a hat the user whether a hat exists for the user or not.
In complain mode, the debug messages are:
Aug 17 16:21:03 zeno sshd[22113]: pam_apparmor(
Aug 17 16:21:03 zeno sshd[22113]: pam_apparmor(
Note, there is not a hat 'gray' defined. If I put it in enforce mode:
Aug 17 17:02:36 zeno sshd[3955]: pam_apparmor(
Aug 17 17:02:36 zeno sshd[3955]: pam_apparmor(
Maybe we're doing something wrong, but I think its broken.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libpam-apparmor 2.5-0ubuntu3
ProcVersionSign
Uname: Linux 2.6.32-
Architecture: i386
Date: Tue Aug 17 18:30:58 2010
InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release i386 (20100427)
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: apparmor
Related branches
Changed in apparmor (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in apparmor (Ubuntu Lucid): | |
importance: | Undecided → Medium |
milestone: | none → lucid-updates |
status: | New → In Progress |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
tags: | added: testcase |
I have reproduced this issue on lucid; it's due to the aa_change_hat(2) call returning -ENOENT when the passed hat doesn't exist, rather than -EPERM or -EACCES that pam_apparmor expects for this situation; instead it treats it as unknown kernel error and aborts. According to John Johanson, this has been the behavior of the kernel portion of apparmor going back to jaunty (and continuing forward in maverick).
It seems to me the right approach to fix this is to teach pam_apparmor the new(er) behavior of the kernel, which ought to be a relatively simple change:
=== modified file 'changehat/ pam_apparmor/ pam_apparmor. c' pam_apparmor/ pam_apparmor. c 2007-03-13 16:52:28 +0000 pam_apparmor/ pam_apparmor. c 2010-08-19 09:00:23 +0000
break;
case EPERM: /* Disable when ECHILD patch gets accepted */
case EACCES:
/* failed to change into attempted hat, so we'll
* jump back out and try the next one */
break;
--- changehat/
+++ changehat/
@@ -167,6 +167,7 @@
+ case ENOENT:
though for apparmor trunk the EPERM case ought to go away.
I note that this is not an issue for the apache2 mod_apparmor, as it continues trying hats in the face of any error returned by the kernel.