Functionality vs Security

[Patrick Williams]

On Wed, Feb 26, 2020 at 05:26:20PM -0600, Joseph Reynolds wrote:
> 
> 
> On 2/25/20 9:52 AM, Patrick Williams wrote:
> > On Thu, Feb 13, 2020 at 08:15:29AM +0000, Mihm, James wrote:
> > > Exposing the REST D-Bus APIs via a network interface is bad practice and should be disabled by default. Just because it was done that way in the beginning doesn’t mean that it should remain that way.
> > > Applications should be configured to be secure by default. Consumers of the code should have to intentionally select an insecure configuration - it shouldn't be provided by default.
> > I'm not going to argue one way or the other with respect to the REST
> > D-Bus API.  I do feel like we're becoming a little too tightly coupled
> > to Redfish though.
> 
> Do you mean you are concerned that the authorization checks are performed in
> BMCWeb, and the D-Bus APIs are expected to be run with root user authority?

No, I don't have as much concern about daemons running as root (which
was the topic of the issue you pointed to below).  My concern is that
we're focusing our efforts on a *specific* implementation inside bmcweb
when we could likely come up with a *general* implementation at the
D-Bus level that gives us similar functionality no matter what the
management interface.

> 
> > When we first put together the REST / D-Bus API we did have discussions
> > on how to secure it.  There isn't anything inherent to that API that
> > makes it any more or less secure than Redfish might be, except for
> > missing code.  D-Bus has policies that can be used to lock down access
> > for specific users.  What we had talked about was creating these
> > policies based on roles and having the REST end-point do something like
> > 'setuid' to the logged in user so that those roles took effect.
> 
> There is a related issue to run daemons as a non-root user.
> https://github.com/openbmc/openbmc/issues/3383
> We tried briefly, hit an authority issue, ran out of time, and haven't got
> back.

What I was referring to was not that the whole bmcweb would run as a
different user but that when it is performing a D-Bus operation on behalf
of a particular user it could de-escalate permissions, for that
operation, similar to what you might do with 'sudo'.

> > By writing all of the access policies inside the webserver based
> > specifically on Redfish requirements, none of that code is helpful for
> > any other management interface.  If those access policies were instead
> > implemented as D-Bus policies then we gain that feature across every
> > management interface available, with SSH being a trivial example.
> > 
> 
> I agree.  Although we are full speed ahead with BMCWeb/Redfish as the
> management interface.  I would welcome some internal authorization controls
> for BMC users.  As far as I know, when SSH'd to the BMC, if you are root:
> you can do everything; if not: your authority is severely limited.

Correct.  We need the D-bus policies in order to allow non-root users to
perform *some* operations (based on the users role).

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200303/75713f9d/attachment.sig>