Functionality vs Security

[Patrick Williams]

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.

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.

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.

-- 
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/20200225/e08a3be8/attachment.sig>