Re: Functionality vs Security

From: Joseph Reynolds <jrey@linux.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>,
	"Mihm, James" <james.mihm@intel.com>
Cc: Brad Bishop <bradleyb@fuzziesquirrel.com>,
	James Feist <james.feist@linux.intel.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Gunnar Mills <gmills@linux.vnet.ibm.com>
Subject: Re: Functionality vs Security
Date: Wed, 26 Feb 2020 17:26:20 -0600	[thread overview]
Message-ID: <a9d059b8-52d1-aa17-937d-7006a591e74d@linux.ibm.com> (raw)
In-Reply-To: <20200225155202.GK67957@patrickw3-mbp.dhcp.thefacebook.com>

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