** Changed in: linux
Status: New => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-ti-omap4 in Ubuntu.
https://bugs.launchpad.net/bugs/748656
Title:
AppArmor complain doesn't always allow requested accesses, doesn't log
errors
Status in The Linux Kernel:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux-ti-omap4 package in Ubuntu:
Fix Released
Status in linux source package in Lucid:
New
Status in linux-ti-omap4 source package in Lucid:
Invalid
Status in linux source package in Maverick:
Invalid
Status in linux-ti-omap4 source package in Maverick:
Invalid
Status in linux source package in Natty:
Fix Released
Status in linux-ti-omap4 source package in Natty:
Fix Released
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/test/program. On a none patched kernel it will return 0 as its
capability set, on a patched kernel it will return the same capability set as
the unconfined run.
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.d/usr.sbin.sshd allowed the logins to succeed. Reloading
the profile and restarting sshd recreates the problem.
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/748656/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
