OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

> On Jan 6, 2018, at 11:57 AM, Michael E Brown <Michael.E.Brown at dell.com> wrote:
> 
> On Thu, Jan 04, 2018 at 10:58:04AM -0600, Michael E Brown wrote:
>> On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
>>> On 22-Dec-2017 05:21 PM, Michael.E.Brown at dell.com wrote:
>>>> We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
>>>> 
>>>> <soapbox mode="on">
>>>> I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
>>>> </soapbox>
>>>> 
>>>> My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
>>>> 
>>>> If you run all the daemons as different users, that tends to sort out design issues.
>>>> 
>>>> Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
>>>> 	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
>>>> 	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
>>>> 	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
>>>> 	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
>>>> 	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
>>>> 	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
>>> 
>>> I fully support your direction with the "run each daemon as its own user"
>>> policy. Almost nothing should be running as root anymore. 
>> 
>> Looks like I need to do some builds and look at this, as I'm operating off old
>> information then.
> 
> We updated our openbmc tree to the latest upstream as of the beginning of Dec, so we are a few weeks out. But I am seeing a discrepancy here when I went and looked that I'd like to figure out. I logged into a build of openbmc running on our development hardware and literally everything in the system is running as root with the exception of DBUS and two systemd daemons. Are we missing something here?
> 
> After seeing the processes all running as root in our build, I examined the service files in the openbmc git repository. I'm looking at the openbmc git repo, and picked some things at random:
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/obmc-fru-fault-monitor.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/xyz.openbmc_project.LED.GroupManager.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-monitor%40.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-presence%40.service
> 
> I examined others as well. None of these files have a User= or Group= directive.
> 
> You can do a "ps -ef | grep phosphor" and see that the second column shows that all of the phosphor processes are running as root, including the web server and processes that listen on the network. This is all very concerning and at odds with anything resembling good security practice.
> 
> What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.

You aren’t missing anything.  I think what Vernon meant was, in 2018, software
stacks should not be running everything as root.

Everyone wants this, it just hasn’t been enough of a priority for anyone
such that it hasn’t been fixed yet.  It should have been done this way in
the first place.  But it wasn’t, so here we are.

FWIW I did add some code to obmc-phosphor-systemd.bbclass quite some time ago
such that configuring a service to run as non-root is trivial, as far as systemd
unit and user/group database configuration goes.  It isn’t used anywhere because
the other side of it is writing the udev rules (or however you want to make sure
the devices have the correct permissions).  I also put code in
obmc-phosphor-dbus-service.bbclass for easy configuration of restrictive dbus
scope permissions that might help with that aspect as well.


> 
> --
> Michael