OpenBMC community telecon - 11/27 Agenda

[Michael.E.Brown at dell.com]

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.

--
Michael

-----Original Message-----
From: Stewart Smith [mailto:stewart at linux.vnet.ibm.com] 
Sent: Thursday, December 21, 2017 6:43 PM
To: Brown, Michael E <Michael_E_Brown at Dell.com>; bradleyb at fuzziesquirrel.com
Cc: vernon.mauery at linux.intel.com; openbmc at lists.ozlabs.org; richard.marian.thomaiyar at linux.intel.com
Subject: RE: OpenBMC community telecon - 11/27 Agenda

Michael.E.Brown at dell.com writes:
> The main issue is one of security. And I realize here that openbmc has a different security model than our product, but here goes:
>
> The "ipmi/web/etc" users are "attacker controlled", if you consider 
> the end-user the adversary and are trying to protect the internal 
> functioning of the product. That may sound a bit off, but the main 
> thing here is that we don't want to allow the user(/administrator) to 
> do something that would break the product or allow an insecure 
> situation. In our product we now have all of our internal daemons 
> running as non-root and a separate user account for each daemon. For
> example: the "powerd" daemon runs as the "power" user and "power"
> group. That linux user has permissions to the /dev entries it needs to 
> function, but does not have access to things like KVM or other 
> infrastructure or hardware that it doesn’t need. Since we allow "ssh"
> logins to a (minimalistic) shell (either racadm or a smash compatible 
> clp), that represents an attack surface. If the user were able to 
> create user called "power" that is a linux user and an ipmi/web user 
> and they logged into the box as that 'power' user, it would be have 
> the same permissions as our power daemon. We try to lock down the 
> default shells for non-privileged users but this would represent a 
> possible entry point.

Neat!

I've thought that OpenBMC would be a good candidate for a really restrictive set of SELinux policy too (or some other security module), to further mitigate any possible damage that could be done even in the event of a vulnerability.

Have you looked into anything like that at all?

--
Stewart Smith
OPAL Architect, IBM.