Proposal add PerformService privilege

Proposal add PerformService privilege

[Joseph Reynolds]

This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb.

See https://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.
- 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.
- Add this privilege to the Administrator role (but not Operator or 
ReadOnly).
- 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?
- Joseph

Re: Proposal add PerformService privilege

[Ed Tanous]

On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>
> This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb.
>
> See https://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?

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

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

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

> - Joseph
>

Re: Proposal add PerformService privilege

[Joseph Reynolds]

On 12/9/20 12:25 PM, Ed Tanous wrote:
> On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds<jrey@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.
- Various manufacturer-specific REST APIs.

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

>> - 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.
- 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.  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
- All the overrides can be build-time configurable; I do not need 
dynamic changes to the privilege registry.

I plan think about this over break,and have a proposal in January 2021.

Thanks!
Joseph

>> - Joseph
>>

Re: Proposal add PerformService privilege

[Ed Tanous]

On Thu, Dec 17, 2020 at 9:31 AM Joseph Reynolds <jrey@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@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
> >>
>