AppArmor complain doesn't always allow requested accesses, doesn't log errors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Undecided
|
|||
linux (Ubuntu) |
Fix Released
|
Undecided
|
John Johansen | ||
Lucid |
Won't Fix
|
Undecided
|
John Johansen | ||
Maverick |
Invalid
|
Undecided
|
John Johansen | ||
Natty |
Fix Released
|
Undecided
|
John Johansen | ||
linux-ti-omap4 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Invalid
|
Undecided
|
Unassigned | ||
Maverick |
Invalid
|
Undecided
|
Unassigned | ||
Natty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
SRU Justification:
Impact: Can result in confined application failure with no information logged on how to fix the problem.
Fix: Do not mask the capabilities returned by capget when in complain mode, this allows the application
to progress as expected and request the capabilities it will need.
Patch from upstream AppArmor, backported for Lucid and Maverick.
Testcase: Run the attached C test program as root. When run unconfined it will output a hex number corresponding to the effective caps of root. Confine the application with a profile in complain mode using aa-genprof /path/to/
Problem was discovered in both upstream kernel and in Ubuntu Natty beta kernels. The problem is a regression from Ubuntu Maverick and earlier releases.
When creating a profile for openssh-server, sshd, using the standard AppArmor profile development tools, a _partial_ profile is created and loaded correctly. When trying to iterate the development of the profile, I found that I was unable to log in to the machine via sshd, even though the AppArmor profile had flags=(complain,) at the beginning.
Removing the profile using apparmor_parser --remove /etc/apparmor.
The logfiles don't show any REJECT messages; a handful of ALLOWED messages are printed early on, but then _no_ log entries are generated.
The client quits with "broken pipe" errors.
Changed in linux (Ubuntu): | |
assignee: | nobody → John Johansen (jjohansen) |
Changed in linux (Ubuntu Maverick): | |
assignee: | nobody → John Johansen (jjohansen) |
Changed in linux (Ubuntu Lucid): | |
assignee: | nobody → John Johansen (jjohansen) |
Changed in linux (Ubuntu Natty): | |
status: | New → Fix Committed |
description: | updated |
Changed in linux-ti-omap4 (Ubuntu Lucid): | |
status: | New → Invalid |
Changed in linux-ti-omap4 (Ubuntu Maverick): | |
status: | New → Invalid |
Changed in linux-ti-omap4 (Ubuntu Natty): | |
status: | New → Fix Committed |
Changed in linux-ti-omap4 (Ubuntu): | |
status: | Fix Committed → Fix Released |
Changed in linux: | |
status: | New → Fix Released |
This is being caused by the apparmor profile masking the capability set, even in complain mode. ssd is requesting the capability set and then modifying its behavior based off of the reduced capability set, and then DAC does the actual reject.
AppArmor doesn't generate any messages hinting at this because,
1. the task checking its capability set is not a privileged operation (it is just masked)
2. sshd is modifying its behavior based on the retrieved capability set and does not ask for or try to use the capabilities it requires, so apparmor does not generate a log message recording which capabilities are needed.
This problem can be worked around by adding capabilities to the profile one by one, and reloading the profile. And testing if the behavior has changed.
It is fixed by not masking the read capability set of the task in complain mode as the task should effectively have all capabilities. Patch attached, and test kernel at
kernel. ubuntu. com/~jj/ linux-image- 2.6.38- 8-generic_ 2.6.38- 8.40~sarnold_ amd64.deb