On Tuesday, May 19 2020, Jamie Strandboge wrote:

> @Sergio, I didn't see that you uploaded anything to the queue so to
> expedite the SRU since there are a number of duplicates, I created a
> smaller backport of the fix and uploaded it to focal-proposed just now:
> http://launchpadlibrarian.net/480473812/apparmor_2.13.3-7ubuntu5_2.13.3-7ubuntu5.1.diff.gz
>
> (I hope that is alright).

Thanks, Jamie!  That's quite alright.  There's an MP opened about this,
but we got sidetracked and forgot to follow up.

Thanks again.

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

-- 
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/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  In Progress

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd:         files systemd
  group:          files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000
  ouid=1000000

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000

  [Regression Potential]

  In order to fix this issue, 3 separate patches had to be backported.
  They are simple and self-contained, especially two of them, whose
  purposes are to add the definition of the @{run} variable and then to
  add a trailing slash at the end of the "/run" pathname.

  The other patch, albeit very simple, adds three statements to the
  'nameservice' profile in order to let processes access (read-only)
  files under "/run/systemd/userdb" and
  "/proc/sys/kernel/random/boot_id".  After thinking about the possible
  cases, the only possible problem I could envision was for a program
  that, not being able to access some of these files before, will now be
  able to do that and therefore exercise a part of its codebase which
  was not being used, possibly uncovering latent bugs in this software.
  But this is not a regression of apparmor per se.

  [Original Description]

  (Description and Test Case were moved above)

  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
    Installed: 2.13.3-7ubuntu4
    Candidate: 2.13.3-7ubuntu4
    Version table:
   *** 2.13.3-7ubuntu4 500
          500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
          100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to