New ServiceRep role and privilege

[Joseph Reynolds]

On 6/21/20 1:52 AM, Thomaiyar, Richard Marian wrote:
> Hi Joseph,
>
> I have added some more points on the use case,
>
> https://redfishforum.com/thread/333/proposed-new-servicerep-role-privilege?page=1&scrollTo=1178 
>
>
> have you made any proposal on it? Last time in security workgroup, i 
> didn't see much interest, but i am interested in getting it defined 
> and propose it to Redfish TF ?
>
> Let me know ?

Richard,  +openbmc

Thanks for your comments on thread/333 above.  I have some of the same 
questions as you.  I think our use cases have very much in common.  I 
had originally formulated ServiceRep and ManufacturingRep roles, with 
different privileges, but we converged them into the ServiceRep role 
that I am taking forward to Redfish.  First, I want to get a direction 
from the Redfish forum for how to handle our use cases.

I created a Redfish issue (https://github.com/DMTF/Redfish/issues/4057) 
to get a direction for adding the ServiceRep role and privilege.  This 
issue is readable only to DMTF Redfish members because the DMTF works 
privately.  I understand this issue will be discussed at the (private) 
Redfish forum meeting planned for this Tuesday June 23, 1-5pm CDT.  Can 
you attend or send a rep from your company?

- Joseph

>
> Regards,
>
> Richard
>
> On 6/4/2020 8:19 AM, Joseph Reynolds wrote:
>> 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.
>>>
>>