add support for DynamicUser feature of systemd

Bug #1869024 reported by Simon Déziel on 2020-03-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Undecided
Jamie Strandboge
apparmor (Ubuntu)
High
Jamie Strandboge

Bug Description

systemd offers to create dynamic (and semi-stable) users for services. This causes many services using Apparmor profiles to trigger those denials (even when they don't use the DynamicUser feature):

audit: type=1107 audit(1585076282.591:30): pid=621 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers" mask="send" name="org.freedesktop.systemd1" pid=709 label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

And more recently with systemd 245 this also get shown:

audit: type=1400 audit(1585139000.628:39): apparmor="DENIED" operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/" pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Additional information:
# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04

# uname -a
Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

# apt-cache policy apparmor squid
apparmor:
  Installed: 2.13.3-7ubuntu2
  Candidate: 2.13.3-7ubuntu2
  Version table:
 *** 2.13.3-7ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status
squid:
  Installed: 4.10-1ubuntu1
  Candidate: 4.10-1ubuntu1
  Version table:
 *** 4.10-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

Simon Déziel (sdeziel) wrote :

As mentioned in LP: #1796911 by xnox, some abstractions should be augmented with the corresponding dbus rules. Support for userdb should also be added IMHO.

Here are the rules that were needed in my tests on an up to date Focal:

  # systemd DynamicUser
  /run/systemd/userdb/ r,
  /run/systemd/userdb/io.systemd.DynamicUser rw,
  @{PROC}/sys/kernel/random/boot_id r,
  #include <abstractions/dbus-strict>
  dbus send
     bus=system
     path="/org/freedesktop/systemd1"
     interface="org.freedesktop.systemd1.Manager"
     member="{GetDynamicUsers,LookupDynamicUserByName,LookupDynamicUserByUID}"
     peer=(name=("org.freedesktop.systemd1")),

The boot_id is a concern for privacy/tracking abuse so I also tried denying it and it doesn't seem to cause visible problems.

description: updated
Changed in apparmor (Ubuntu):
status: New → Fix Committed
status: Fix Committed → In Progress
importance: Undecided → High
assignee: nobody → Jamie Strandboge (jdstrand)
Jamie Strandboge (jdstrand) wrote :

FYI, I added these accesses in https://github.com/snapcore/snapd/pull/8443

Changed in snapd:
status: New → In Progress
assignee: nobody → Jamie Strandboge (jdstrand)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.13.3-7ubuntu4

---------------
apparmor (2.13.3-7ubuntu4) focal; urgency=medium

  * debian/apparmor.service: add /var/lib/snapd/apparmor/profiles to
    RequiresMountsFor since Ubuntu's rc.apparmor.functions looks for it
    (LP: #1871148)
  * libnss-systemd.patch: allow accessing the libnss-systemd VarLink sockets
    and DBus APIs. Patch partially based on work by Simon Deziel.
    (LP: #1796911, LP: #1869024)
  * upstream-mr-424-kerberos-dot-dirs.patch: abstractions/kerberosclient:
    allow reading /etc/krb5.conf.d/
  * upstream-mr-442-gnome-user-themes.patch: gnome abstraction: allow reading
    per-user themes from $XDG_DATA_HOME (Closes: #930031)
  * upstream-mr-443-ecryptfs-dirs.patch: abstractions/base: allow read access
    to top-level ecryptfs directories (LP: #1848919)
  * upstream-mr-445-uuidd-request.patch: abstractions/base: allow read access
    to /run/uuidd/request
  * upstream-mr-464-Mesa_i915_perf_interface.patch: let Mesa check if the
    kernel supports the i915 perf interface. Patch from Debian

 -- Jamie Strandboge <email address hidden> Mon, 06 Apr 2020 17:47:20 +0000

Changed in apparmor (Ubuntu):
status: In Progress → Fix Released
Simon Déziel (sdeziel) wrote :

@jdstrand, asked in #systemd about @{PROC}/sys/kernel/random/boot_id and didn't get much information back. That said, https://github.com/systemd/systemd/blob/master/docs/RANDOM_SEEDS.md#systemds-use-of-random-numbers says:

> At various places systemd needs random bytes for temporary file name generation, UID allocation randomization, and similar.

As such, I believe this should be permitted.

Jamie Strandboge (jdstrand) wrote :

The abstraction is meant to cover the client, not systemd internal specifics. A client simply accessing that DBus API won't need it and a client simply accessing those sockets won't need it. It very well might be that a profiled application is using some *ctl command from systemd that would need it, but in that case said command would need to be added to the policy and the boot-id could be added at that time.

On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
> The abstraction is meant to cover the client, not systemd internal
> specifics. A client simply accessing that DBus API won't need it and a
> client simply accessing those sockets won't need it. It very well might
> be that a profiled application is using some *ctl command from systemd
> that would need it, but in that case said command would need to be added
> to the policy and the boot-id could be added at that time.

I don't know as squid, named and samba (to name a few) generate many
denials trying to read /proc/sys/kernel/random/boot_id. None of those
are explicitly trying to use the DynamicUser feature. Could it be just a
side effect of how nsswitch.conf is setup by default?

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

Maybe you'd prefer this to be reported/discussed in a separated LP?

Regards,
Simon

Simon Déziel (sdeziel) wrote :

On 2020-04-11 9:04 p.m., Simon Déziel wrote:
> On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
>> The abstraction is meant to cover the client, not systemd internal
>> specifics. A client simply accessing that DBus API won't need it and a
>> client simply accessing those sockets won't need it. It very well might
>> be that a profiled application is using some *ctl command from systemd
>> that would need it, but in that case said command would need to be added
>> to the policy and the boot-id could be added at that time.
>
> I don't know as squid, named and samba (to name a few) generate many
> denials trying to read /proc/sys/kernel/random/boot_id. None of those
> are explicitly trying to use the DynamicUser feature. Could it be just a
> side effect of how nsswitch.conf is setup by default?
>
> $ grep systemd /etc/nsswitch.conf
> passwd: files systemd
> group: files systemd

This is indeed due to having systemd in the default nsswitch.conf. I've
report the problem in LP: #1872564

Simon

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers