OpenBMC community telecon - 11/27 Agenda

[Michael E Brown]

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.

--
Michael