OpenBMC community telecon - 11/27 Agenda

[Michael E Brown]

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.

> I don't have any SELinux experience, so it is great to have someone in the
> community that does and is willing to drive that.

Thanks

> Have you considered using user namespaces to avoid username collisions with
> system users and user-chosen names (like if an IPMI user wanted to pick
> 'root' as the name)? I have seen people demonstrate how you can use
> containers to do this, but I have not yet figured out how it all works.

I've given this a little bit of thought. Yes, you could use some user
namespaces for this, though to be honest I don't really think it buys all that
much. You can limit ptrace with yama and basically protect the users from each
other pretty well that way, all using a single account. But we could add user
namespaces here as well. The hard part would be in figuring out how to do dbus
level security. I think we'll need to have a unified policy around security of
dbus to tie everything together.

> The reason I don't like the NSS mechanism with a single unix user that you
> proposed is that it allows users to attack each other, which can lead to
> privilege escalations as well. If the non-system users are namespaced, they
> can be called whatever they want and have whatever ID they want, but as far
> as the kernel goes, they are separate users and all non-root.

I think the overriding question here is what kind of shell access do we want to
give to users of openbmc, and what permissions do we want to give them in the
shell? If we want as a project to have the default openbmc "ssh" access be to a
bash shell, then we need to do a lot more around security to get this all to
work well. This is also going to be very difficult to make sure we get
everything correct, however, it is do-able.

On Dell's product, we have a custom shell, and users don't have any generic
system access. Users have no write access to any filesystems, so there is no
way for any logged in user to attack another user via a file.  This pretty
effective in our product.

If we want to have openbmc give shell access to users, lets figure out what
that looks like from a security perspective.

NSS/PAM and one "linux" account, lets call it 'bmcuser'. We'll call the
accounts that users use "bmc accounts". (for example, user could create 'user1'
and 'user2' and those would not show up as linux accounts) It would be
relatively straightforward, I believe, to ensure that one bmc account cannot
attack another bmc account even if both are running in the same linux account,
either with or without namespaces.

With or without namespaces:
	- Need a way to unambiguously set security policy so that things like
dbus calls can have appropriate security applied. Likely the best way to do
this is via normal linux groups. Then we need a comprehensive policy for dbus
to apply the group security policy. This way, we can apply policy for shell
users when they do things like busctl, or use cli utilities that make dbus
calls.
	- Need to ensure that all writable filesystems are mounted noexec to
prevent silly shell attacks.

Without namespaces: 
	- use the yama security patches to disable ptrace for non-children. 
	- possibly use seccomp to disable ptrace() 
	- possibly use seccomp to disable kill()

With namespaces:
	- set bmcuser login shell to a special wrapper which spawns new
namespace, sets groups appropriately, and exec's shell.

--
Michael