← Back to team overview

kernel-packages team mailing list archive

[Bug 1473584] Re: AUDIT_USER_AVC messages are not printk'ed when auditd is not running

 

This bug was fixed in the package linux-goldfish - 3.4.0-4.24~15.04.1

---------------
linux-goldfish (3.4.0-4.24~15.04.1) vivid; urgency=low

  [ Upstream Kernel Changes ]

  * audit: printk USER_AVC messages when audit isn't enabled
    - LP: #1473584

 -- Tim Gardner <tim.gardner@xxxxxxxxxxxxx>  Mon, 13 Jul 2015 14:57:44
-0700

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-manta in Ubuntu.
https://bugs.launchpad.net/bugs/1473584

Title:
  AUDIT_USER_AVC messages are not printk'ed when auditd is not running

Status in linux-flo package in Ubuntu:
  Fix Released
Status in linux-goldfish package in Ubuntu:
  Fix Released
Status in linux-mako package in Ubuntu:
  Fix Released
Status in linux-manta package in Ubuntu:
  Fix Released
Status in linux-flo source package in Vivid:
  Fix Released
Status in linux-goldfish source package in Vivid:
  Fix Released
Status in linux-mako source package in Vivid:
  Fix Released
Status in linux-manta source package in Vivid:
  Fix Released

Bug description:
  The auditd daemon is not part of the default phone images. At the
  kernel level, the audit_enabled variable remains 0 until an auditd
  daemon registers itself. There is a bug in old kernels that causes
  AUDIT_USER_AVC messages to be ignored when audit_enabled is 0. I fixed
  the bug several years ago and marked the patch for the stable tree but
  the phone kernels (mako, at least) did not pull in the patch. The
  upstream commit id is:

    0868a5e150bc4c47e7a003367cd755811eb41e0b

  What this means for our phone images is that any denial messages from
  the system D-Bus daemon are dropped instead of being properly routed
  to the syslog. This results in headaches for debugging app confinement
  denials.

  == Verification Steps ==

  # Load an AppArmor profile for testing
  $ echo "profile test { file, signal, unix, }" | sudo apparmor_parser -rq

  # Verify that we can talk to the system bus
  $ dbus-send --print-reply --system --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
  method return sender=org.freedesktop.DBus -> dest=:1.90 reply_serial=2
     array [
        string "org.freedesktop.DBus"
     ...

  # Clear the dmesg buffer
  $ sudo dmesg -C

  # Attempt to talk to the system bus under confinement
  $ aa-exec -p test -- dbus-send --print-reply --system --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
  Failed to open connection to "system" message bus: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

  # We should now see an AppArmor denial in the dmesg output.
  # Successful fix verification *must* show the denial from the D-Bus daemon.
  $ sudo dmesg | grep DENIED
  [  187.737219] type=1107 audit(1438385684.065:149): pid=826 uid=102 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=6721 label="test" peer_label="unconfined"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-flo/+bug/1473584/+subscriptions


References