Contribute a systemd workload attestator plugin

[zecke]

pluginName: systemd pluginType: workloadattestor description: A basic plugin to get the systemd.unit for the running pid. pluginData: No config right now Github Repo: https://github.com/zecke/systemd-attestor

[evan2645]

Thank you for opening this @zecke! I wonder what other interesting selectors we could get from systemd...

I noticed that this implementation uses dbus to communicate with systemd. Can you help me understand the security posture of dbus given this usage? For example, how do we know we're speaking to the "real" systemd, is it possible for an unprivileged user to somehow impersonate it, etc...

[amartinezfayo]

In addition to Evan's questions, I'm wondering what are the requirements to run the dbus calls? Would it be always available in systems where systemd is enabled?

[zecke]

dbus is the native interface to systemd. There are two modes to reach the systemd process:

• /run/systemd/private unix domain socket. This can be used to speak dbus protocol to systemd for uid=0 processes.

• Through the dbus-daemon over a unix domain socket. On a well configured system the socket is in a well known directory that is only writable by uid=0 (e.g. /run/dbus/system_bus_socket). AFAIK the dbus-daemon is configured to:

  1. dbus-daemon has a cli option to know about systemd and a config file that sort of claims this bus name (https://github.com/systemd/systemd/blob/c5b6b4b6d08cf4c16a871401358faeb5a186c02a/src/core/org.freedesktop.systemd1.service)
  2. Limit the methods used by non root users (https://github.com/systemd/systemd/blob/c5b6b4b6d08cf4c16a871401358faeb5a186c02a/src/core/org.freedesktop.systemd1.conf)
  3. Very restrictive policy of which names and users can request names on the system bus.

On a system configured to run systemd as /sbin/init it is unlikely that a non-privileged can ever assume the org.freedesktop.systemd1 bus name.

On a system without systemd it is likely that there is a dbus-daemon policy in place that forbids owning a name on the system bus.

I can see two cases where a rogue answer can be given:

1. A rogue system manages to register (first) with the spire server.
2. On a compromised system.

Which aspect shall we drill into? Do we have an example how we treat the kubelet for k8s?

[evan2645]

Thank you for the detailed reply @zecke

On a well configured system ... On a system configured to run systemd as /sbin/init it is unlikely that a non-privileged can ever assume the org.freedesktop.systemd1 bus name.

Unlikely as in, systemd (as init) is in a position such that it will always be the first to register/claim it?

Maybe it is possible for us to detect the above-referenced configurations, to validate that the system is in a state that makes it safe to use this dbus target/name? And if so, what sort of things would we want to validate?

On a system without systemd it is likely that there is a dbus-daemon policy in place that forbids owning a name on the system bus.

Ok, that would be good. Perhaps we can validate that this is the case for either default systemd install, default POPULAR_DISTRO_HERE install, or both

I can see two cases where a rogue answer can be given:

1. A rogue system manages to register (first) with the spire server.
2. On a compromised system.

This is useful. I don't think we need to worry about 2 since the assumption is that if the machine is owned then the agent is owned.

[evan2645]

Sorry, I missed one!

Do we have an example how we treat the kubelet for k8s?

By default, the k8s workload attestor validates the kubelet's TLS server certificate

[adobley]

TL;DR: We believe it is safe to assume that we are speaking to the real systemd, because impersonation would require a root process.

Impersonation of dbus/systemd is incredibly difficult. dbus and systemd config can only be written by root, at which point the system is compromised anyway. dbus is configured by default to prevent all users from claiming any messagebus names on the system bus. The default systemd dbus configuration file only allows root processes to claim the systemd name.

It does look like the major distros don’t mess with the dbus/systemd configs. I would expect that allowing someone else to claim arbitrary names or even claim the systemd name specifically would be a security risk beyond our SPIRE use case. I hope that no distro would make this mistake. Specifically, we checked that the systemd name can only be owned by root for:

• centos-7
• fedora28
• ubuntu-trusty64
• opensuse42
• rhel-7.3
• debian-contrib-testing64

If systemd isn’t configured, meaning that the org.freedesktop.systemd1.conf file isn't present, then no one can claim that name. The default in dbus is to deny the claiming of names. The systemd dbus config is what allows that name to be claimed by root, assuming that a root user doesn’t change those defaults.

The configuration files for dbus are at /usr/share/dbus-1/system.conf on newer systems. The older location for this configuration file was /etc/dbus-1/system.conf. These files can also include other conf files using includedir directives. Those files tend to live in child directories of /usr/share/dbus-1 or /etc/dbus-1.

Just for reference, in case we want to verify the configuration using these files, the permissions for owning a name are declared under a policy directive looking something like:

<policy context="default">
	<deny own="*"/>
</policy>

<policy context="root">
	<allow own="org.freedesktop.systemd1"/>
</policy>

There might be a way to query dbus to discover these permissions more programmatically, but we have not found that.

• @srwaggon and @adobley

[evan2645]

Thank you for digging into this @srwaggon and @adobley!

@zecke are you still up for sending this contribution? We'd be very happy to have it.

[zecke]

SGTM.

[blaggacao]

Since the entirety of NixOS is based on systemd, and NixOS is an increasingly popular base distribution for infrastructure management, I'd be very interested in this being officially supported.

[rkaippully]

I am another NixOS user and would love to see this supported as well. @zecke do you still plan to contribute this plugin? If nobody else is actively working on it, I can take a stab at it.