Re: systemd-devel Digest, Vol 155, Issue 8

["Lal, Arun" <arun.lal@xxxxxxxxx>]

Hi Lennart,

In function check_access I see the following code. 

if (c->vtable->flags & SD_BUS_VTABLE_UNPRIVILEGED)
                return 0;

Can you tell me what is the right way to mark a dbus-interface as SD_BUS_VTABLE_UNPRIVILEGED?
Because marking it as SD_BUS_VTABLE_UNPRIVILEGED means my non-root user can make the dbus-call without getting access denied. 

I see SD_BUS_METHOD function used in bus_manager_vtable to add entry to vtable. But this involves code changes in systemd. 
I want to know if there a way to mark a interface as SD_BUS_VTABLE_UNPRIVILEGED without changing code. Like through configuration files etc. 

Regards,
Arun Lal K M

-----Original Message-----
From: Lennart Poettering <lennart@xxxxxxxxxxxxxx> 
Sent: Monday, March 13, 2023 5:18 PM
To: Lal, Arun <arun.lal@xxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  systemd-devel Digest, Vol 155, Issue 8

On Sa, 11.03.23 08:29, Lal, Arun (arun.lal@xxxxxxxxx) wrote:

> 1) Dbus uses .conf files in /etc/dbus-1/system.d/ or /usr/share/dbus-1/system.d/ to allow and deny access to dbus method calls.
>     And what is the point of allowing a user in these conf files if
>     eventually systemd will block the call?

so, I think you are mixing up things. the caps thing is a red herring i guess.

We definitely support polkit in systemd. but it has nothing to do with caps.

dbus policy is mostly a useless concept, it's too static and riid. it nowadays has been largely supplanted by polkit: thus the low-level dbus policy for most services is just configured to be open, and the services use polkit to authenticate the calls and refuse them if polkit says no or cannot be reached.

> 2) Why is "busctl call" to slandered interfaces such as org.freedesktop.DBus.Peer still work even if caller is non-root.
>
> 3) I see that busctl commands such as "tree", "introspect" etc., are 
> still allowed for non-root user. So why is there a restriction "call"?

I don't understand that question.

method calls systemd#s services provide are usually protected by at least three levels: dbus policy (which as mentioned we mostly configure to be entirely open), polkit, and then selinux if that's available. Only if all three say "yes" we'll allow a call to go through.

In none of the three cases process capabilities come into the mix though, as mentioned in the other mail: we cannot use them for authenticating in userspace securely.

Lennart

--
Lennart Poettering, Berlin