Proposal add PerformService privilege

[Ed Tanous]

On Thu, Dec 17, 2020 at 9:31 AM Joseph Reynolds <jrey at linux.ibm.com> wrote:
>
> On 12/9/20 12:25 PM, Ed Tanous wrote:
> > On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds<jrey at linux.ibm.com>  wrote:
> >> This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb.
> >>
> >> Seehttps://redfishforum.com/thread/397/redfish-direction-update-eeproms
> >> As mentioned in the Redfish forum thread, the use case is that some
> >> OpenBMC use cases require isolating manufacturing and service functions
> >> away from the customer/admin (including updating FRU serial numbers, and
> >> updating a permanent MAC address), and this is a Redfish compatible way
> >> to do it.
> >>
> >> The work items would be like:
> >> - Add this OEM privilege to the base BMCWeb implementation.
> > Can you talk through how you would do this mechanically?  Today, we
> > rely on privilege registry (published from DMTF) to guide these roles
> > and urls.  Now that you've invented a new role, how do you plan on
> > fitting that in?  Will it be required for all systems?  Will it be
> > optional?  Will it only apply to OEM schemas?
>
> Note: Around the same this this email was sent, we discussed this in the
> Security working group 2020-12-09, with minutes here:
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
>
> Here are the basics of the low level design:
> #. Enhance redfish-core/include/privileges.hpp -- add the new
> "OEMPerformService" privilege.
> #. Enhance redfish-core/lib/roles.hpp -- add OEMPerformService to thje
> existing Administrator role && add the new "ServiceAgent" role #ifdef's
> by a new config option.
> #. Modify the privilege map for individual operations as appropriate to
> require the OEMPerformService privilege.
>
> However, you are correct that this may not be the best approach. See below.
>
>
> >> - Identify URIs that we need to be able to isolate away from
> >> customer/admins.  Then modify the privilege mapping to require this
> >> privilege to PUT to those URIs.
> > What URLs have what privileges is already defined by DMTF in the base
> > privilege registry.  What you're talking about would require a
> > customizable privilege registry, which definitely needs some
> > significant thought, as the current privileges mechanisms in bmcweb
> > are very static today.  Just "customizable privileges registry" is
> > probably a design on its own, and would likely need to land before
> > adding OEM privilege levels.
>
> That makes sense.  However, some URIs are outside the scope of Redfish
> including:
> - The URI named by the Assembly BinaryDataURI property.

Do we support this yet?  It seems like the BinaryDataURI would follow
the same permissions as the equivalent property/resource within
redfish.  With that said,

> - Various manufacturer-specific REST APIs.
This confuses me a little.  Manufacturer specific rest APIs will have
their own privilege/authorization systems, similar to how IPMI has its
own privilege system.  While they're related, the other manufacturer
rest APIs can apply whatever permissions they like.  Within redfish,
they would appear as something like "OEM<Company API name>Privilege"
and be orthogonal to Redfish privileges, as it's a totally separate
API;

>
> >> - Add this privilege to the Administrator role (but not Operator or
> >> ReadOnly).
> > If we're adding this privilege to the Administrator role, how does it
> > differ from ConfigureManager role?
>
> The main idea is that the Redfish-defined Administrator role *by
> default* has all Redfish standard privileges.  But I don't think this
> applies to OEM privileges, so I am re-thinking this point.
> My point remains that I need a separate OEMPerformService privilege;
> having this privilege enables my Enterprise Server system to remove this
> privilege from admins, and give it to my service agents.
> I'm not sure if I understood or answered your question.

"I need to create a new privilege and apply it to certain endpoints"
is a use case covered by Redfish and well understood in a fully
functioning PrivilegeRegistry implementation.  We just don't have a
configurable privilege registry setup yet.

>
> >> - Document how to isolate these operations.  Specifically, remove this
> >> privilege from Administrator, and create a custom OEM role that has this
> >> privilege
> >>
> >> What do you think?
> > I think we've got a couple designs that would need to land ahead of
> > this before we'd have the infrastructure and documentation to build
> > something like this.
> >
> >
> > The designs I see coming before this are:
> > Static PrivilegeRegistry implementation
> > modifiable/dynamic Per-URI privilege registry implementation
> > modifiable/dynamic Per-property privilege registry implementation
> > OemOpenBMCPerformService registry added.
>
> Yes, we discussed this in the workgroup call.
>
> Specifically, we discussed making a better privilege registry
> implementation.  Redfish (DSP0266) defines an operation-to-privilege
> mapping and is represented as a Privilege Registry.
>
> BMCWeb currently implements the Redfish authorization model as a mapping
> from URI -> HTTP verb -> privileges.  The privilege overrides are
> hard-coded in C++ in each operation handler.
>
> If I understood this correctly, the first step is to enhance BMCWeb to
> directly use the published Redfish PrivilegeRegistry (such as
> Redfish_1.0.4_PrivilegeRegistry.json).  Elements includes:
> - Add new build step to convert the PrivilegeRegistry file into C++ code
> that implements the authority checking.  The main ideas are: a
> downstream implementation can easily customize their PrivilegeRegistry
> and it will automatically build into the code. And performing the
> authority check must be fast and efficient.

Sounds exactly right.  When we first wrote the existing privileges
system, we actually had a script that automated this, but that was on
an old machine that's now defunct, so it's probably gone and certainly
out of date.  With that said, it was a trivial amount of code.

> - The set of privileges is part of the Privilege Registry, and its
> implementation should be enhanced accordingly.
> - Handling the basic "privilege and and or syntax clauses" is
> straightforward.

The existing privileges system is already set up to handle and/or
clauses per the redfish schema, you just need to generate the correct
set of bracketed C++ structures (same as you see in the Node class)
for it to read in.

>  Handling Resource URI overrides seems
> straightforward.  Handling property overrides I need to think about
> more.  And I am not aware that BMCWeb has any Subordinate overrides

Yep, the per property stuff gets hard, as we don't really do "per
property" code.  In the next few years of Redfish development, I
suspect this problem will come up more and more and we'll need to
start breaking out individual properties into their own little world.

> - All the overrides can be build-time configurable; I do not need
> dynamic changes to the privilege registry.

Sounds good.

>
> I plan think about this over break,and have a proposal in January 2021.
>
> Thanks!
> Joseph
>
> >> - Joseph
> >>
>