jsauthority: add 'system_unit' and 'no_new_privileges' subject attributes

When building with libsystemd support, query the systemd unit name
that the process if part of (if any) and add it as a subject attribute.
Allows allow-listing actions based on the systemd unit:

 polkit.addRule(function(action, subject) {
     if (action.id.indexOf("org.foo.bar") == 0) {
         if (subject.system_unit == "test.service" && subject.no_new_privileges) {
             return polkit.Result.YES;
         }
     }
 });

We call it system_unit instead of just unit to make it extra clear that
this is about system units, rather than user units.
If we ran as root we could also query for the user unit, but we are
running as the polkitd user in most cases which means we cannot connect
to other D-Bus sessions to perform the query.

We only do this if we can pin the subject process by PIDFD, as that's
safer PIDs can be recycled. Skip if not possible because the D-Bus
daemon and/or systemd are too old and do not support the functionality.
Also we check for the NoNewPrivileges= being set, so that we can ensure
that the unit cannot alter its uid via a setuid binary. But let this last
part be decided by policy, as a system builder might simply ensure that
no setuid binaries are shipped at all, which is equivalent.

This requires dbus-broker v34 or dbus-daemon v15.7 and systemd v253 and
kernel v6.5.

1 files changed, 41 insertions, 0 deletions

diff --git a/docs/man/polkit.xml b/docs/man/polkit.xml
index b67c4a6..081f72a 100644
--- a/docs/man/polkit.xml
+++ b/docs/man/polkit.xml
@@ -798,6 +798,19 @@ May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:4:
         </varlistentry>
 
         <varlistentry>
+          <term><type>string</type> system_unit</term>
+          <listitem>
+            <para>
+              The systemd unit that the subject's process is part of (if any). Note that
+              this can only match on system units, as user units can be created with any
+              name without privileges (unlike system units which require root to create).
+              A process running in a user unit will return the user session unit in this
+              attribute (e.g.: <literal>user-1000.service</literal>).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
           <term><type>boolean</type> local</term>
           <listitem>
             <para>
@@ -807,6 +820,19 @@ May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:4:
         </varlistentry>
 
         <varlistentry>
+          <term><type>boolean</type> no_new_privileges</term>
+          <listitem>
+            <para>
+              Set only if <parameter>system_unit</parameter> is not empty, and set to
+              <constant>true</constant> only if the referenced systemd service unit
+              has the <parameter>NoNewPrivileges=</parameter> setting enabled. This
+              ensures that the process cannot gain any new privileges via executing
+              setuid binaries.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
           <term><type>boolean</type> active</term>
           <listitem>
             <para>
@@ -946,6 +972,21 @@ polkit.addRule(function(action, subject) {
     }
 });
 ]]></programlisting>
+
+      <para>
+        Allow all processes running as part of the <literal>admin.service</literal>
+        systemd system unit to perform user administration, as long as they cannot
+        gain new privileges:
+      </para>
+      <programlisting><![CDATA[
+polkit.addRule(function(action, subject) {
+    if (action.id == "org.freedesktop.accounts.user-administration" &&
+        subject.system_unit == "admin.service" &&
+        subject.no_new_privileges) {
+        return polkit.Result.YES;
+    }
+});
+]]></programlisting>
     </refsect2>
   </refsect1>