Functionality vs Security

[Brad Bishop]

> On Feb 12, 2020, at 5:58 PM, James Feist <james.feist at 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 at 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 at 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.