New ServiceRep role and privilege

[Joseph Reynolds]

This is a proposal to add a new ServiceRep role and a new PerformService 
privilege to Redfish.  The motivation for this is given in the "Isolate 
service privileges" email, as archived [1].

To be clear: This email is asking the OpenBMC community for input before 
approaching Redfish with a formal proposal.  Would you be okay with the 
changes described here, or do we have more considerations?

The proposal

1. Add a new PerformService privilege with description: Can perform 
service operations on components that this service manages.
Reference: Update DSP2046 Redfish Resource and Schema Guide > 
PrivilegeRegistry > Property details.

2. Add a new ServiceRep role with the same privileges as Operator, plus 
the PerformService privilege.
ServiceRep - Login, ConfigureComponents, ConfigureSelf, PerformService.
Reference: DSP0266 Redfish Specification > Security Details > Privilege 
model and authorization.

3. Update the Administrator role to optionally have the PerformService 
privilege.  Make this an implementation decision based on use case:
- As an Administrator of a system that does not have dedicated service 
personnel, I need the PerformService privilege so I don't have to create 
a service account just to perform service operations.
- As the OEM of a system that has dedicated service agents, I need the 
Administrator to NOT have the PerformService privilege so they cannot 
interfere with the service personnel.

4. Change various operations to require the PerformService privilege.  
For example, allow PATCH to an EthernetInterface MACAddress.

4a. Reference: DSP8010 Redfish Schema > EthernetInterface.
Change the MACAddress.readonly property to false.

4b. Reference: DSP8011 > Redfish PrivilegeRegistry > EthernetInterface.
Add a PropertyOverride to target MACAddress for the PATCH operation: 
require PerformService.


Discussion points

I believe this would be straightforward to implement in the BMCWeb 
Redfish server [2].  For point 3 above (optionally assigning the 
PerformService privileges), we can have an BMCWeb configuration option 
or image feature.  I believe we need both use cases.

Note that ServiceRep may need the ConfigureManagers privilege depending 
on your service model.  Note also that a ServiceRep with the 
ConfigureUsers privilege is really an Administrator with additional 
powers, as discussed in the OpenBMC security working group minutes [3] 
from 2019-11-21 and 2020-03-04.  That may or may not be what you want.  
All kinds of fun here, we could even make this configurable by the BMC 
admin. [4]

To address how to protect against DSP2045 > "AccountService roles allow 
an escalation of privileges", see discussion in the "Isolate service 
privileges" email [1].

The proposal described here does not fit neatly into the existing 
Redfish model.  The PerformService privilege should optionally be 
assigned to the Administrator role, depending on the use case. Perhaps 
the Redfish spec could make that an implementation option. Otherwise 
using a custom Role and OemPrivileges (as shown in the DSP0266 > 
OEMSysAdminPriv example) would work.  We'll need to work that out with 
Redfish.

The alternate proposal using a custom Role & OemPrivileges would be:
- Custom ServiceRep role, as above.
- OemPrivilegePerformService, as above.
- But with no changes to the Redfish spec.
- A configuration option that determines whether or not Administrator 
contains OemPrivilegePerformService.

Is this the right way to think about alternate role and privilege 
schemes, or is using custom roles and OemPrivileges the way to go?

- Joseph

[1]: https://lists.ozlabs.org/pipermail/openbmc/2020-June/021927.html
[2]: https://github.com/openbmc/bmcweb
[3]: 
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
[4]: Just joking.  That's extra works we don't need.