add support for DynamicUser feature of systemd

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.

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

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

@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.

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

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

I'm marking the snapd task as fix released, for 2.45 based on the history of the referenced pull request.