New ServiceRep role and privilege

[Joseph Reynolds]

On 6/3/20 9:31 PM, Joseph Reynolds wrote:
> 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?

I posted this topic to the Redfish forum to get their input: 
https://redfishforum.com/thread/333/proposed-new-servicerep-role-privilege

- Joseph

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