All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mihm, James" <james.mihm@intel.com>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>,
	James Feist <james.feist@linux.intel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Gunnar Mills <gmills@linux.vnet.ibm.com>,
	Joseph Reynolds <jrey@linux.ibm.com>
Subject: RE: Functionality vs Security
Date: Thu, 13 Feb 2020 08:15:29 +0000	[thread overview]
Message-ID: <C599FC839619124CAC44E062ABB7DFE2D7BAF2D5@ORSMSX115.amr.corp.intel.com> (raw)
In-Reply-To: <F59054FF-546F-4728-B569-CF94AB88CC96@fuzziesquirrel.com>

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?

  reply	other threads:[~2020-02-13  8:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 21:16 Functionality vs Security James Feist
2020-02-12 21:58 ` Joseph Reynolds
2020-02-12 22:13   ` Bruce Mitchell
2020-02-12 22:01 ` Brad Bishop
2020-02-12 22:06   ` James Feist
2020-02-12 22:36     ` Brad Bishop
2020-02-12 22:58       ` James Feist
2020-02-12 23:36         ` Brad Bishop
2020-02-12 22:25   ` Derick Montague
2020-02-13  0:05 ` Brad Bishop
2020-02-13  0:11   ` James Feist
2020-02-13  0:50     ` Brad Bishop
2020-02-13  0:52       ` James Feist
2020-02-13  3:05     ` Brad Bishop
2020-02-13  8:15       ` Mihm, James [this message]
2020-02-13 16:36         ` Brad Bishop
2020-02-13 21:09           ` Functionality vs Security - security assurance methodology Joseph Reynolds
2020-02-25 15:52         ` Functionality vs Security Patrick Williams
2020-02-26 23:26           ` Joseph Reynolds
2020-03-03 22:41             ` Patrick Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C599FC839619124CAC44E062ABB7DFE2D7BAF2D5@ORSMSX115.amr.corp.intel.com \
    --to=james.mihm@intel.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=gmills@linux.vnet.ibm.com \
    --cc=james.feist@linux.intel.com \
    --cc=jrey@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.