daemons should not run as root

[joseph-reynolds]

This is a meta-issue is to change existing daemons to run as a non-root user.

The security issue:

• OpenBMC has many daemon processes running with high privilege levels, typically as the root user.
• When a daemon running as root is compromised, the attacker will have root access to the BMC. (See https://en.wikipedia.org/wiki/Privilege_escalation.)
• The mitigation is to run the daemon as a non-root user who has the least amount of privilege it needs (see https://en.wikipedia.org/wiki/Principle_of_least_privilege). Privilege is typically capabilities (http://man7.org/linux/man-pages/man7/capabilities.7.html) and file permissions.
• Then when the daemon is compromised, it gives the attacker less power.

https://unix.stackexchange.com/questions/206779/is-it-a-good-practice-to-run-a-daemon-under-a-non-root-user-account

TODO: Create an issue (in the correct repo) for each OpenBMC daemon running as root. Each daemon will need to determine what privileges it needs. We'll probably have to create at least one additional user (which might be used for multiple daemons) and change systemd config files.

[edtanous]

At a system level, we need to solve the dbus permissions issue to close this issue.

bmcweb at one point did run as its own user (and that user still exists on the system) but upon moving from boost-dbus to the sdbusplus interfaces, there was an issue with accessing resources on the system dbus interface when running as non-root. We had someone debug it for close to 2 weeks before giving up and just running the webserver as root.

These permission issues would need to be resolved before any sdbusplus service could be moved to a non-root user.

[joseph-reynolds]

We'll have to determine appropriate file permissions and group permissions at the same time, and set permissions according to the principle of least privilege.
For example, control applications may need to access sysfs device files but they should not have any access to web application files. Why? Even if the control app would never intentionally access those files, an attacker may cause them to read the files and leak the information, thus causing a security exposure. Similarly, the web server should not have access to sysfs device files. Thus, we might think about having separate security domains.

[edtanous]

"at the same time" As a matter of rolling out this change slowly, permissions can be overly permissive to start with, then we can slowly transition to more secure filesystem permissions.
Perfect is the enemy of good. Even just getting the applications moved to the correct users, even with a lot of the filesystem set to 0777 has advantages.
Looking forward to seeing your patchsets start showing up on the above.

[jmbills]

Where we ran into trouble is in https://github.com/systemd/systemd/blob/0a2fcbd2eefe2257f622576e1f9f15608a3b6e19/src/libsystemd/sd-bus/bus-convenience.c#L533

When attempting to start other units or call methods as a non-root daemon, the function sd_bus_query_sender_privilege() is eventually called. This function has UID checks that detect non-root users and block the action.

This caused issues when we had two daemons (bmcweb and a cpu-logger) running as non-root. If bmcweb attempted to call a method on the cpu-logger, the method call was blocked by the above UID check.

[joseph-reynolds]

Thanks for the updates. My two initial posts were merely to record my intention. I'm glad someone else is interested in this.

I am agreed that we can change to non-root as a first step and curious what you tried. Did you switch from root to nonroot (uid=1000 or whatever) in the daemon to retain all the Linux process capabilities (http://man7.org/linux/man-pages/man7/capabilities.7.html)? Or did you switch before exec'ing the daemon like in bmcweb.service?

[joseph-reynolds]

I'm not sure if looking at Linux process capabilities is the right direction.
I need to understand how OpenBMC uses the D-Bus authorization model. My understanding is:

1. We are using the system bus (not session buses).
2. All of our daemons currently run as root (but we want to change them so they run as non-root).
3. D-Bus treats a process running as root (uid=0) as special, so it can message anywhere it likes.
4. Messages from daemons run as non-root are blocked because of the authorization failure.

If my understanding is correct, can we somehow authorize these non-root daemons to write messages to other applications on the system bus? I imagine that we'll want multiple non-root users, each from a separate set of processes. Example domains: one set for all control apps that need write authority to sysfs files, another set for control apps that go between D-Bus and REST APIs, and a third set for web apps that don't need any D-Bus or sysfs authorization.

I checked the D-Bus spec (https://dbus.freedesktop.org/doc/dbus-specification.html) which mentions authentication protocols, but I couldn't figure out how to use the protocol to allow a non-root process to write message to a root process D-Bus app. The D-Bus man pages talk about sd_bus_creds, but I couldn't figure out how to create the creds needed to talk to my root-owned app.

Specifically, my question is: how do I change one of my daemons which used to run as root to run as non-root and still be able to send and receive D-Bus messages from different non-root users?

[joseph-reynolds]

Per https://unix.stackexchange.com/questions/194308/d-bus-authentication-and-authorization, I think we just need the right UNIX domain credentials (SCM_CREDENTIALS or SO_PEERCRED). For example, in each systemd .service file:

[Service]
User=someuser
Group=root   --or--
SupplementaryGroups=root

If this works, daemon processes do not run as root (and can be run as different users), and they can exchange dbus messages with each other. So this is a step in the right direction. (However, because group=root the processes can access more files than we would like, further work is needed to shut off that access.)

[joseph-reynolds]

We discussed this briefly at the 2019-03-06 security working group meeting. Maybe this is a bug that nobody else sees because they use Policy Kits (polkit)?

[stale]

This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions.

[stale]

This issue has been closed because no activity has occurred in the last 7 months. Please reopen if this issue should not have been closed. Thank you for your contributions.

[bradbishop]

This is still needed.

[alext-w]

Looking at the https://github.com/systemd/systemd/blob/0a2fcbd2eefe2257f622576e1f9f15608a3b6e19/src/libsystemd/sd-bus/bus-convenience.c#L533 function listed by @jmbills as the culprit, I see it actually checks for process capabilities first, only then resorts to simplified E/UID checks. So probably capabilities could help us here at the end of the day. Or maybe better understanding of the D-Bus authentication and whether it could be used here at all. All in all, it, I believe, is a quite important thing to achieve, to have most or our daemons running as non-root, because currently that's clearly surplus and it opens up a necessarily wide attack capabilities for any compromised process.

@joseph-reynolds, I'd propose to revisit this during the next Security WG meeting and maybe try to define more specific next steps to start moving here.

[joseph-reynolds]

This is an instance of CWE-250: Execution with Unnecessary Privileges.

[joseph-reynolds]

Copied from #openbmc IRC chat: Would it help to use systemd-nspawn to help isolate processes?

[alext-w]

Would it help to use systemd-nspawn to help isolate processes?

This looks like yet another containerization solution. While it would indeed provide the root powers isolation, would it really allow the containerized workload to communicate over hosts' D-Bus? My understanding from some reading (I don't have any first-hand experience with this one) is that it won't. It also performs full filesystem isolation, as they claim, including /dev so I wonder whether systemd-nspawn'ed daemons will actually be able to do anything useful.

And of course performance is another concern here, while being lightweight, this is still some additional work for the CPU to do, so it should at least be benchmarked.

All in all, it IMHO doesn't looks like something that would help, but some actual trial may be useful here.

[stale]

This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions.

[ya-mouse]

I currently working on this issue.

[stale]

This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions.

[geissonator]

@ya-mouse still chugging away on this one stalebot

[stale]

This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions.