Functionality vs Security

[Joseph Reynolds]

On 2/12/20 3:16 PM, James Feist wrote:
> In IRC yesterday I proposed the question of whether to change the 
> default of bmcweb to disable REST D-Bus, or to change it in our 
> meta-layers only. I created the patch here: 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344 and I am 
> looking for feedback. While REST D-Bus does expose many useful APIs, 
> and phosphor-webui depends heavily on it, it does leak information to 
> any logged in user. This comes to the question, should we prefer 
> functionality by default or security by default? It is a compile 
> switch either way, so each user can still decide which they prefer. I 
> have the opinion that the default should be the safest configuration, 
> and if someone wants to change that, then they can accept the risk and 
> change the build flag.
>
> Thoughts?

Thanks for the email.  Some thoughts to help illuminate the situation....

OpenBMC ought to be "secure by default".  I agree the Rest-DBus APIs 
represent an unnecessary information exposure, albeit only to 
authenticated users.  That is, I have no doubt the APIs should be 
disabled by default.

I understand the reason why the D-Bus APIs are enabled-by-default is 
because they were developed first, before the Redfish APIs were 
available.  And I understand the direction and current efforts are to 
develop Redfish APIs to replace all D-Bus APIs, then disable the D-Bus 
APIs by default.

In that context, you are asking if this can happen now.  Let's explore that:

If we disable D-Bus APIs now, we'll also disable the web access. Users 
who don't use web access will not be affected.  Anyone who wants web 
access can easily configure their bmcweb recipe to re-enable the D-Bus 
APIs.  ==> In the future (a year from now?) when the web app is using 
only Redfish APIs (and no longer using any D-Bus APIs), the bmcweb 
recipes can be changed back.

(The project really needs a build-time  security configuration guide.)

- Joseph

BMCWEB_ENABLE_DBUS_REST:
https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt

>
> Thanks,
>
> James