kernel-packages team mailing list archive

[Mathew Hodson <mathew.hodson@xxxxxxxxx>]

** 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