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