touch-packages team mailing list archive

[Chris J Arges <1425398@xxxxxxxxxxxxxxxxxx>]

Hello Pavel, or anyone else affected,

Accepted rsyslog into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/rsyslog/7.4.4-1ubuntu2.6 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: rsyslog (Ubuntu Trusty)
       Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398

Title:
  Apparmor uses rsyslogd profile for different processes - utopic HWE

Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in linux-lts-utopic package in Ubuntu:
  Invalid
Status in rsyslog package in Ubuntu:
  Fix Released
Status in apparmor source package in Trusty:
  In Progress
Status in linux source package in Trusty:
  Confirmed
Status in linux-lts-utopic source package in Trusty:
  Invalid
Status in rsyslog source package in Trusty:
  Fix Committed

Bug description:
  [rsyslog impact]
  This bug prevents rsyslog from receiving all events from other services on trusty when the utopic-hwe (and newer) kernels are used. The rsyslog SRU adds an additional permission (read access to /dev/log) to the rsyslog apparmor policy to allow this to work.

  [rsyslog test case]
  (1) Ensure the rsyslog apparmor policy is set to enforce; it should show up listed in the "XX  profiles are in enforce mode." section reported by "sudo aa-status" (if it's disabled, do "sudo aa-enforce rsyslogd").

  (2) Install the utopic or newer hwe enablement stack reboot into the
  kernel. Using the logger(1) utility should generate log messages (e.g.
  "logger foo") that are recorded in syslog; with this bug, they will be
  blocked (grep DENIED /var/log/syslog).

  [rsyslog regression potential]
  The only change to rsyslog in the SRU is a slight loosening of the rsyslog apparmor policy. The risk of an introduced regression is small.

  [rsyslog addition info]
  The qa-regression-testing script is useful for verifying that rsyslog is still functioning properly (http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-rsyslog.py)
   

  [Original description]
  I've noticed that apparmor loads /usr/sbin/rsyslogd profile for completely unrelated processes:

  Feb 25 08:36:19 emma kernel: [  134.796218] audit: type=1400 audit(1424842579.429:245): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=4002 comm="sshd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  Feb 25 08:36:23 emma kernel: [  139.330989] audit: type=1400 audit(1424842583.965:246): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=4080 comm="sudo" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  Feb 25 08:35:42 emma kernel: [   97.912402] audit: type=1400 audit(1424842542.565:241): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=2436 comm="whoopsie" requested_mask="r" denied_mask="r" fsuid=103 ouid=0
  Feb 25 08:34:43 emma kernel: [   38.867998] audit: type=1400 audit(1424842483.546:226): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=3762 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  I'm not sure how apparmor decides which profile to use for which task,
  but is shouldn't load '/usr/sbin/rsyslogd' profile for sshd/ntpd/etc.

  I'm running:
  # lsb_release -rd
  Description:	Ubuntu 14.04.2 LTS
  Release:	14.04

  # dpkg -l | grep apparmor
  ii  apparmor                            2.8.95~2430-0ubuntu5.1               amd64        User-space parser utility for AppArmor
  ii  apparmor-profiles                   2.8.95~2430-0ubuntu5.1               all          Profiles for AppArmor Security policies
  ii  apparmor-utils                      2.8.95~2430-0ubuntu5.1               amd64        Utilities for controlling AppArmor
  ii  libapparmor-perl                    2.8.95~2430-0ubuntu5.1               amd64        AppArmor library Perl bindings
  ii  libapparmor1:amd64                  2.8.95~2430-0ubuntu5.1               amd64        changehat AppArmor library
  ii  python3-apparmor                    2.8.95~2430-0ubuntu5.1               amd64        AppArmor Python3 utility library
  ii  python3-libapparmor                 2.8.95~2430-0ubuntu5.1               amd64        AppArmor library Python3 bindings

  # uname -a
  Linux emma 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1425398/+subscriptions