OpenBMC community telecon - 11/27 Agenda

[Stewart Smith]

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.