Re: [systemd-devel] systemctl as non-root
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? If you do not use D-Bus daemon systemd will be listening on private socket. In this case the only check it does is that peer runs as UID=0 (note - not EUID, so suid does not really help). I think with or without dbus systemd listens on the private socket (/run/systemd/private). No, private socket is used only as fallback when full D-Bus is not available. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On 29 May 2015 at 01:21, aaron_wri...@selinc.com wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. the term dbus is used loosely and it's a few distinct things. On the most basic level, it's used as a marshalling/demarshling format of messages passed to/from systemd, on the protocol level this is exposed via private socket or systemd may join the system bus which is operated by something, e.g. kdbus or the dbus1 daemon. When there is a dbus daemon available policy can be checked and enforced and e.g. unprivilledged users can be granted to execute certain actions on per dbus api level. Further more policykit can be used in conjunction with that to seamlessly ask to elevate / allow more privileged api calls. However just on the private systemd socket these complex measures are not available and one really needs to be root... ... if not done carefully, it is easy to introduce vulnerabilities into the system e.g. if one allows unprivileged things start/stop privileged jobs. On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov arvidj...@gmail.com wrote:
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote:
I'm working on an embedded system, and I ran into a situation where
a non-root user needs to runs systemctl, but when I try I get:
~ $ systemctl status
Failed to get D-Bus connection: No such file or directory
So, I try with the suid bit on systemctl set, but then I get:
~ $ systemctl status
Failed to read server status: Operation not permitted
My question is, is something broken, or is this expected behavior?
If you do not use D-Bus daemon systemd will be listening on private
socket. In this case the only check it does is that peer runs as UID=0
(note - not EUID, so suid does not really help).
I think with or without dbus systemd listens on the private socket
(/run/systemd/private).
No, private socket is used only as fallback when full D-Bus is not available.
I don't think so.
root@lnxumuttl:/home/umuttl/Development# strace -f systemctl 21 | grep connect
connect(3, {sa_family=AF_LOCAL, sun_path=/run/systemd/private}, 22) = 0
root@lnxumuttl:/home/umuttl/Development# systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Tue 2015-05-26 16:43:56 CEST; 2 days ago
Docs: man:dbus-daemon(1)
Main PID: 967 (dbus-daemon)
CGroup: /system.slice/dbus.service
└─967 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On 05/29/2015 05:26 AM, Andrei Borzenkov wrote: If you do not use D-Bus daemon systemd will be listening on private socket. In this case the only check it does is that peer runs as UID=0 (note - not EUID, so suid does not really help). I wonder how access control is implemented in kdbus case. kdbus implements its own policy logic to allow given UIDs to talk to, see, or own well-known-names. See kdbus.policy(7) in the standalone kdbus repository. For individual method calls, kdbus can optionally pass a number of metadata along, so services can in some cases make authorization decisions based on them, without talking to polkit. This is similar to SCM_CREDENTIALS on sockets but offers a lot more information. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, 29.05.15 10:54, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov arvidj...@gmail.com
wrote:
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote:
I'm working on an embedded system, and I ran into a situation where
a non-root user needs to runs systemctl, but when I try I get:
~ $ systemctl status
Failed to get D-Bus connection: No such file or directory
So, I try with the suid bit on systemctl set, but then I get:
~ $ systemctl status
Failed to read server status: Operation not permitted
My question is, is something broken, or is this expected behavior?
If you do not use D-Bus daemon systemd will be listening on private
socket. In this case the only check it does is that peer runs as UID=0
(note - not EUID, so suid does not really help).
I think with or without dbus systemd listens on the private socket
(/run/systemd/private).
No, private socket is used only as fallback when full D-Bus is not
available.
I don't think so.
root@lnxumuttl:/home/umuttl/Development# strace -f systemctl 21 | grep
connect
connect(3, {sa_family=AF_LOCAL, sun_path=/run/systemd/private}, 22) = 0
root@lnxumuttl:/home/umuttl/Development# systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Tue 2015-05-26 16:43:56 CEST; 2 days ago
Docs: man:dbus-daemon(1)
Main PID: 967 (dbus-daemon)
CGroup: /system.slice/dbus.service
└─967 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
We always listen on the private socket. We also listen on the proper
bus, but only if dbus-daemon is actually running.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Thu, 28.05.15 17:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Long story short: you cannot avoid dbus IPC really. Please use dbus-daemon, it's recommended. If you choose not to anyway, then you will not have access to systemd's APIs from unprivileged APIs. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, May 29, 2015 at 1:02 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.05.15 17:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Hmm, in a kdbus world, systemd (the service) itself would be responsible for policy checks anyway, wouldn't it? I mean, it already does the polkit/selinux checks even on dbus1 systems. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, 29.05.15 13:56, Mantas Mikulėnas (graw...@gmail.com) wrote: systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Hmm, in a kdbus world, systemd (the service) itself would be responsible for policy checks anyway, wouldn't it? I mean, it already does the polkit/selinux checks even on dbus1 systems. Correct. However, it does so in cooperation with sd-bus and kdbus. kdbus provides per-method call credentials, which allows us to properly authenticate the individual method call. kdbus also does per-service access control, and sd-bus provides support for defining access control for methods in a static way. All together in systemd on kdbus there are four layers of access checks applied: 1. kdbus own per-service policy 2. sd-bus' static per-method capability based checks, as declared in the object vtables 3. dynamic access control on objects, enforced by systemd itself based on capabalities, uids, and policykit 4. selinux checks based on object and client labels Only if all four layers allow access, access is actually granted. In the long run I hope to add some more helpers to make it easier to implement the schemes of #3 in external services. Currently we have some internal glue that makes invocation of policykit easy, but we should probably provide a public API for that right in sd-bus, too. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Long story short: you cannot avoid dbus IPC really. Please use dbus-daemon, it's recommended. If you choose not to anyway, then you will not have access to systemd's APIs from unprivileged APIs. Well, that clears that up. Thanks for the detailed responses. Given my product's embedded nature, I'm trying to run a minimal systemd, as I've mentioned before. This has, of course, caused me to run into lots of issues of my own making. So thanks for bearing with me. I'd like to do without yet another daemon, dbus-daemon, on the system, so I'll work around the non-root systemctl access, which isn't too hard my specific situation. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Thu, May 28, 2015 at 9:21 PM, aaron_wri...@selinc.com wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. That's not what --disable-dbus means..please read the configure description.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
В Thu, 28 May 2015 17:21:14 -0700 aaron_wri...@selinc.com пишет: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? If you do not use D-Bus daemon systemd will be listening on private socket. In this case the only check it does is that peer runs as UID=0 (note - not EUID, so suid does not really help). I wonder how access control is implemented in kdbus case. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
