[systemd-devel] systemd-devel Digest, Vol 155, Issue 8

[Lal, Arun]

Hi Lennart,

This makes lot of sense. 😊 

The main objective I am looking for is to let the non-root user make a dbus-call to an application running in root. 
And as per your last mail it seems possible through polkit. Will it be possible for you to show me a reference to how this can be done using polkit? 

And from where can I learn how systemd code handles polkit configuration. Is there any documentation? 
It will also be good if you could give be a very high level brief on how polkit configuration allow/deny access to a user in making method calls. And which part of systemd code handles this. 

And let me clear up some confusion I created earlier.
- We can forget about caps discussion as it is not my main objective. It was something I thought could help, while going through code. 
And you have given me enough clarity on this 😊

Regards,
Arun Lal K M

-----Original Message-----
From: Lennart Poettering <lennart at poettering.net> 
Sent: Monday, March 13, 2023 5:18 PM
To: Lal, Arun <arun.lal at intel.com>
Cc: systemd-devel at lists.freedesktop.org
Subject: Re: [systemd-devel] systemd-devel Digest, Vol 155, Issue 8

On Sa, 11.03.23 08:29, Lal, Arun (arun.lal at intel.com) 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