Functionality vs Security

Functionality vs Security

[James Feist]

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,

James

Re: 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

Re: Functionality vs Security

[Brad Bishop]

Hi James

> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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.

There is no user that prefers something that doesn’t work or is incomplete, no matter how secure it is.  If you can find one, I’m happy to be proven wrong.

In my mind, the only user that wants this is Intel, because Intel has a bunch of patches to the webui that would make the broken upstream work.  The path forward here is simple (in concept) - upstream your webui patches, and the need for this to even be a discussion point goes away.  Has Intel had issues getting the webui patches upstreamed?

> I have the opinion that the default should be the safest configuration

I completely agree!  This disconnect is what should we entertain calling a configuration.  I say that configurations that break existing (working) usage patterns of the upstream project code are not on the table.

thx - brad

Re: Functionality vs Security

[James Feist]

On 2/12/20 2:01 PM, Brad Bishop wrote:
> Hi James
> 
>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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.
> 
> There is no user that prefers something that doesn’t work or is incomplete, no matter how secure it is.  If you can find one, I’m happy to be proven wrong.

To my knowledge the only thing that breaks is the Web-UI, if you don't 
find the Web-UI useful, then I don't think it matters much.

> 
> In my mind, the only user that wants this is Intel, because Intel has a bunch of patches to the webui that would make the broken upstream work.  The path forward here is simple (in concept) - upstream your webui patches, and the need for this to even be a discussion point goes away.  Has Intel had issues getting the webui patches upstreamed?

We had someone working on the Web-UI, but they had problems getting 
things merged due to differences in design opinions. Unfortunately that 
person has moved on, so the up-streaming effort has been halted for now.

> 
>> I have the opinion that the default should be the safest configuration
> 
> I completely agree!  This disconnect is what should we entertain calling a configuration.  I say that configurations that break existing (working) usage patterns of the upstream project code are not on the table.

It doesn't break it, it's just a default that you can switch back with a 
single build flag. This is only changing a default.

> 
> thx - brad
> 

RE: Functionality vs Security

[Bruce Mitchell]

Please remember that a "disgruntled employee" can be " authenticated user" and there for a Security Threat.

-----Original Message-----
From: openbmc [mailto:openbmc-bounces+bruce_mitchell=phoenix.com@lists.ozlabs.org] On Behalf Of Joseph Reynolds
Sent: Wednesday, February 12, 2020 13:58
To: James Feist; OpenBMC Maillist
Cc: Brad Bishop; Gunnar Mills; Mihm, James
Subject: Re: Functionality vs Security

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

Functionality vs Security

[Derick Montague]

> We had someone working on the Web-UI, but they had problems getting
things merged due to differences in design opinions. Unfortunately that
person has moved on, so the up-streaming effort has been halted for now.

We made some progress with finding consensus on design changes. The biggest
issue we struggled with was the size of the commits and the coupling of the
design and functionality changes. As we build out the Vue.js rewrite, we are
using Redfish.

Re: Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 5:06 PM, James Feist <james.feist@linux.intel.com> wrote:
> 
> On 2/12/20 2:01 PM, Brad Bishop wrote:
>> Hi James
>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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.
>> There is no user that prefers something that doesn’t work or is incomplete, no matter how secure it is.  If you can find one, I’m happy to be proven wrong.
> 
> To my knowledge the only thing that breaks is the Web-UI, if you don't find the Web-UI useful, then I don't think it matters much.

The project test automation suite would also break.  What if you do find the Web-UI (or test automation suite) useful?  Who gets to decide what the “important” usage patterns are that need to be maintained and which ones don’t and can be allowed to break with changes like this?

I think we should take a cue from Linux.  The answer is _all_ usage patterns are important and must be maintained.  I don’t see why we should be any different.

> 
>> In my mind, the only user that wants this is Intel, because Intel has a bunch of patches to the webui that would make the broken upstream work.  The path forward here is simple (in concept) - upstream your webui patches, and the need for this to even be a discussion point goes away.  Has Intel had issues getting the webui patches upstreamed?
> 
> We had someone working on the Web-UI, but they had problems getting things merged due to differences in design opinions.

I don’t understand how design differences would present problems in getting back-end api calls switched over to Redfish.  It sounds like the commits were not structured properly or there were design changes mixed in with functional changes.

> 
>>> I have the opinion that the default should be the safest configuration
>> I completely agree!  This disconnect is what should we entertain calling a configuration.  I say that configurations that break existing (working) usage patterns of the upstream project code are not on the table.
> 
> It doesn't break it, it's just a default that you can switch back with a single build flag. This is only changing a default.

If I clone openbmc and try to run the webui, will it still work after this change?  If I clone openbmc and run the test automation suite against that, will it still work after this change?

Re: Functionality vs Security

[James Feist]

On 2/12/20 2:36 PM, Brad Bishop wrote:
> 
> 
>> On Feb 12, 2020, at 5:06 PM, James Feist <james.feist@linux.intel.com> wrote:
>>
>> On 2/12/20 2:01 PM, Brad Bishop wrote:
>>> Hi James
>>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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.
>>> There is no user that prefers something that doesn’t work or is incomplete, no matter how secure it is.  If you can find one, I’m happy to be proven wrong.
>>
>> To my knowledge the only thing that breaks is the Web-UI, if you don't find the Web-UI useful, then I don't think it matters much.
> 
> The project test automation suite would also break.  What if you do find the Web-UI (or test automation suite) useful?  Who gets to decide what the “important” usage patterns are that need to be maintained and which ones don’t and can be allowed to break with changes like this?

My POV it makes the feature look like it's done, when it's not. And it's 
better to know where the holes are.

> 
> I think we should take a cue from Linux.  The answer is _all_ usage patterns are important and must be maintained.  I don’t see why we should be any different.

It'll still work fine with the correct config, just like KCONFIG choices.

> 
>>
>>> In my mind, the only user that wants this is Intel, because Intel has a bunch of patches to the webui that would make the broken upstream work.  The path forward here is simple (in concept) - upstream your webui patches, and the need for this to even be a discussion point goes away.  Has Intel had issues getting the webui patches upstreamed?
>>
>> We had someone working on the Web-UI, but they had problems getting things merged due to differences in design opinions.
> 
> I don’t understand how design differences would present problems in getting back-end api calls switched over to Redfish.  It sounds like the commits were not structured properly or there were design changes mixed in with functional changes.

I wasn't heavily involved, maybe you're right, not sure. Regardless 
they're gone now.

> 
>>
>>>> I have the opinion that the default should be the safest configuration
>>> I completely agree!  This disconnect is what should we entertain calling a configuration.  I say that configurations that break existing (working) usage patterns of the upstream project code are not on the table.
>>
>> It doesn't break it, it's just a default that you can switch back with a single build flag. This is only changing a default.
> 
> If I clone openbmc and try to run the webui, will it still work after this change?  If I clone openbmc and run the test automation suite against that, will it still work after this change?

Sure, as long as the target has the bbappend with 
DBMCWEB_ENABLE_DBUS_REST=ON enabled. I'm writing the opposite patch now 
for our platforms.

> 

Re: Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 5:58 PM, James Feist <james.feist@linux.intel.com> wrote:
> 
> On 2/12/20 2:36 PM, Brad Bishop wrote:
>>> On Feb 12, 2020, at 5:06 PM, James Feist <james.feist@linux.intel.com> wrote:
>>> 
>>> On 2/12/20 2:01 PM, Brad Bishop wrote:
>>>> Hi James
>>>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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.
>>>> There is no user that prefers something that doesn’t work or is incomplete, no matter how secure it is.  If you can find one, I’m happy to be proven wrong.
>>> 
>>> To my knowledge the only thing that breaks is the Web-UI, if you don't find the Web-UI useful, then I don't think it matters much.
>> The project test automation suite would also break.  What if you do find the Web-UI (or test automation suite) useful?  Who gets to decide what the “important” usage patterns are that need to be maintained and which ones don’t and can be allowed to break with changes like this?
> 
> My POV it makes the feature look like it's done, when it's not.

Software isn’t ever done - it evolves.  I can tell you it was "done enough" for a number of companies.  We aren’t ever going to find universal consensus on what “done” is because everyone uses the code in different ways.  This is why _all_ usage patterns are important and must be maintained.

> And it's better to know where the holes are.
> 
>> I think we should take a cue from Linux.  The answer is _all_ usage patterns are important and must be maintained.  I don’t see why we should be any different.
> 
> It'll still work fine with the correct config, just like KCONFIG choices.

If you find a KCONFIG option that enables a feature that doesn’t work, that is a bug in the eyes of 100% of the kernel community.

> 
>>> 
>>>> In my mind, the only user that wants this is Intel, because Intel has a bunch of patches to the webui that would make the broken upstream work.  The path forward here is simple (in concept) - upstream your webui patches, and the need for this to even be a discussion point goes away.  Has Intel had issues getting the webui patches upstreamed?
>>> 
>>> We had someone working on the Web-UI, but they had problems getting things merged due to differences in design opinions.
>> I don’t understand how design differences would present problems in getting back-end api calls switched over to Redfish.  It sounds like the commits were not structured properly or there were design changes mixed in with functional changes.
> 
> I wasn't heavily involved, maybe you're right, not sure. Regardless they're gone now.

Ok.  Since this is the work that needs to be done to get secure-by-default that Intel wants so badly, why was this person re-allocated?

> 
>>> 
>>>>> I have the opinion that the default should be the safest configuration
>>>> I completely agree!  This disconnect is what should we entertain calling a configuration. I say that configurations that break existing (working) usage patterns of the upstream project code are not on the table.
>>> 
>>> It doesn't break it, it's just a default that you can switch back with a single build flag. This is only changing a default.
>> If I clone openbmc and try to run the webui, will it still work after this change?  If I clone openbmc and run the test automation suite against that, will it still work after this change?
> 
> Sure, as long as the target has the bbappend with DBMCWEB_ENABLE_DBUS_REST=ON enabled. I'm writing the opposite patch now for our platforms.

As of today, OpenBMC users (as in a system vendor or integrator) don’t need to write a bbappend to get a working webui.  They shouldn’t need to do that.  They shouldn’t be burdened with that.

Re: Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
> 
> James

One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.

This is still a workaround - what really needs to happen is (most of) the webui and test automation suites need to be ported to Redfish, and when that happens, the need for this new distro policy set goes away - at least in terms of legacy REST API enablement.

Would this be a satisfactory compromise?

-brad

Re: Functionality vs Security

[James Feist]

On 2/12/20 4:05 PM, Brad Bishop wrote:
> 
> 
>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
>>
>> James
> 
> One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.

I would rather see OpenBMC by default secure. I don't want to see CVEs 
caused by an insecure default configuration in anybody's platform.

> 
> This is still a workaround - what really needs to happen is (most of) the webui and test automation suites need to be ported to Redfish, and when that happens, the need for this new distro policy set goes away - at least in terms of legacy REST API enablement.
> 
> Would this be a satisfactory compromise?
> 
> -brad
> 

Re: Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 7:11 PM, James Feist <james.feist@linux.intel.com> wrote:
> 
> On 2/12/20 4:05 PM, Brad Bishop wrote:
>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
>>> 
>>> James
>> One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.
> 
> I would rather see OpenBMC by default secure.

I would as well.  This is why I would like to see the webui patches upstreamed.

> I don't want to see CVEs caused by an insecure default configuration in anybody's platform.

Is anyone planning on opening a CVE?

-brad

Re: Functionality vs Security

[James Feist]

On 2/12/20 4:50 PM, Brad Bishop wrote:
> 
> 
>> On Feb 12, 2020, at 7:11 PM, James Feist <james.feist@linux.intel.com> wrote:
>>
>> On 2/12/20 4:05 PM, Brad Bishop wrote:
>>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
>>>>
>>>> James
>>> One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.
>>
>> I would rather see OpenBMC by default secure.
> 
> I would as well.  This is why I would like to see the webui patches upstreamed.
> 
>> I don't want to see CVEs caused by an insecure default configuration in anybody's platform.
> 
> Is anyone planning on opening a CVE?

I'm not aware of any.

> 
> -brad
> 

Re: Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 7:11 PM, James Feist <james.feist@linux.intel.com> wrote:
> 
> On 2/12/20 4:05 PM, Brad Bishop wrote:
>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
>>> 
>>> James
>> One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.
> 
> I would rather see OpenBMC by default secure. I don't want to see CVEs caused by an insecure default configuration in anybody's platform.

Can you talk more about how this doesn’t meet the goals?  The user always has to pick a distro, so there is a conscious choice between the two.  There wouldn’t be any default with a setup like this.

I guess it is possible to have nodistro, which would be the true default.  I wouldn’t have an issue with these setups:

DISTRO= #nodistro -> full paranoia by default
DISTRO=openbmc-phosphor -> full function by default
DISTRO=openbmc-lockdown -> full paranoia by default

or just:
DISTRO= #nodistro -> full paranoia by default
DISTRO=openbmc-phosphor -> full function by default

would either of these meet the goals?

RE: Functionality vs Security

[Mihm, James]

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. 

With phosphor-webui being replaced by webui-vue, there's not much value for us to upstream our changes to phosphor-webui. Regarding the resource issues, we're having to respond to decisions that were out of our control. 

James.

-----Original Message-----
From: Brad Bishop <bradleyb@fuzziesquirrel.com> 
Sent: Wednesday, February 12, 2020 7:05 PM
To: James Feist <james.feist@linux.intel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Gunnar Mills <gmills@linux.vnet.ibm.com>; Mihm, James <james.mihm@intel.com>; Joseph Reynolds <jrey@linux.ibm.com>
Subject: Re: Functionality vs Security



> On Feb 12, 2020, at 7:11 PM, James Feist <james.feist@linux.intel.com> wrote:
> 
> On 2/12/20 4:05 PM, Brad Bishop wrote:
>>> On Feb 12, 2020, at 4:16 PM, James Feist <james.feist@linux.intel.com> 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,
>>> 
>>> James
>> One idea I have is adding a new distro configuration.  Today we have openbmc-phosphor - we could add a DISTRO=openbmc-secure-at-all-costs to meta-phosphor, and the legacy API could be disabled by default there, and remain enabled by default in openbmc-phosphor.
> 
> I would rather see OpenBMC by default secure. I don't want to see CVEs caused by an insecure default configuration in anybody's platform.

Can you talk more about how this doesn’t meet the goals?  The user always has to pick a distro, so there is a conscious choice between the two.  There wouldn’t be any default with a setup like this.

I guess it is possible to have nodistro, which would be the true default.  I wouldn’t have an issue with these setups:

DISTRO= #nodistro -> full paranoia by default
DISTRO=openbmc-phosphor -> full function by default
DISTRO=openbmc-lockdown -> full paranoia by default

or just:
DISTRO= #nodistro -> full paranoia by default
DISTRO=openbmc-phosphor -> full function by default

would either of these meet the goals?

Re: Functionality vs Security

[Brad Bishop]

> On Feb 13, 2020, at 3:15 AM, Mihm, James <james.mihm@intel.com> wrote:
> 
> Exposing the REST D-Bus APIs via a network interface is bad practice and should be disabled by default.

Yeah.  You are right of course.  It isn’t really the what that bothers me here it is the how.  I’m disappointed that Intel was only able to make the Redfish enabled webui work for Intel and not anyone else.

> Just because it was done that way in the beginning doesn’t mean that it should remain that way.

I don’t remember saying this?

> Applications should be configured to be secure by default.

This sounds perfectly reasonable of course but I don’t know how to implement it for OpenBMC.  I’m not even sure what it means.  Security isn’t a boolean it is a spectrum.  Show me any security posture, and I will show you one that is slightly more strict/secure.  Clearly, my security posture isn’t strict enough for Intel.  However I know there are organizations out there that have even stricter security postures than Intel.  So in the general case - how does one decide which posture should be the default, and when is ok to “break” existing usage patterns rather than “update” them for the sake of a stricter security posture?  Help me establish some rules so we can avoid this kind of bickering in the future.

thx
-brad

Re: Functionality vs Security - security assurance methodology

[Joseph Reynolds]

On 2/13/20 10:36 AM, Brad Bishop wrote:
>
>> On Feb 13, 2020, at 3:15 AM, Mihm, James <james.mihm@intel.com> wrote:
>>
>> Exposing the REST D-Bus APIs via a network interface is bad practice and should be disabled by default.
> Yeah.  You are right of course.  It isn’t really the what that bothers me here it is the how.  I’m disappointed that Intel was only able to make the Redfish enabled webui work for Intel and not anyone else.
>
>> Just because it was done that way in the beginning doesn’t mean that it should remain that way.
> I don’t remember saying this?
>
>> Applications should be configured to be secure by default.
> This sounds perfectly reasonable of course but I don’t know how to implement it for OpenBMC.  I’m not even sure what it means.  Security isn’t a boolean it is a spectrum.  Show me any security posture, and I will show you one that is slightly more strict/secure.  Clearly, my security posture isn’t strict enough for Intel.  However I know there are organizations out there that have even stricter security postures than Intel.  So in the general case - how does one decide which posture should be the default, and when is ok to “break” existing usage patterns rather than “update” them for the sake of a stricter security posture?  Help me establish some rules so we can avoid this kind of bickering in the future.

Brad,

Thanks for that introduction.  We're working on a way to answer 
questions like this in the [OpenBMC security assurance workflow][] which 
promises to address all security items using world-class practices.

Yes, literally all security items.  There are some excellent references 
out there that we are trying to use.  (footnote1)

For example, a key point in the Cloud Security Industry Summit > "[CSIS 
Secure Firmware Development Best Practices][]" > "BMC" section is to 
"Document all available interfaces" specifically including Redfish 
APIs.  A security review would find the D-Bus APIs, and raise suspicion.

Most security assurance methodologies begin with an architectural review 
of the system and drill down to all external interfaces.  We need that 
for OpenBMC.  The hard part is getting the right level of abstraction 
because the use cases and details are different, so nothing is merged 
yet.  The current attempt (in review), 
[architecture/interface-overview][], describes how BMCWeb serves REST 
APIs (which includes the D-Bus APIs).  I hope we can merge this as a 
simplified view of the BMC's primary interfaces.

Anyway, that's how I see the security story playing out for OpenBMC ... 
using OpenBMC security assurance workflow as the way to organize all 
OpenBMC security documentation and talk about which pieces are 
relatively more important.  When these docs are ready, we can refer to 
them as we continue to bicker and argue in a more sophisticated way.

- Joseph

P.S. I gave my opinion about the D-Bus APIs in a separate email, 
archived here: 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020501.html

(footnote1): Don't expect any miracles though, because following the 
security assurance methodology is a lot of difficult work and requires 
cooperation between folks in different disciplines.  And we're just 
getting started.  And all the big words makes peoples' brains hurt.

[OpenBMC security assurance workflow]: 
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-assurance-workflow

[CSIS Secure Firmware Development Best Practices]: 
https://github.com/opencomputeproject/Security/blob/master/SecureFirmwareDevelopmentBestPractices.md#bmc

[architecture/interface-overview]: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/27969

> thx
> -brad

Re: Functionality vs Security

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Functionality vs Security

[Joseph Reynolds]

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?

> 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.

>
> 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.

- Joseph

Re: Functionality vs Security

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]