New Redfish roles for ServiceRep and OemRep
jrey at linux.ibm.com
Tue Feb 18 11:48:58 AEDT 2020
On 2/17/20 1:29 AM, Thomaiyar, Richard Marian wrote:
> We need to make sure user account are not getting created in this role
> by end-user. i.e. when creating a new user, these options must not be
> provided. We need to have a separate way of selecting this role or
> instead of not defining as role, we can add this as some mode in redfish.
Yes, I am looking for a solution to this: I don't want a BMC admin to be
able to create a user account and escalate their privilege to the
ServiceRep or OemRep role. Only the Oem and Service organizations
(which may be different) should be able to access the BMC with these roles.
Redfish offers no help here and simply notes that the BMC admin can
become whatever role they want. It's up to us to define what we need.
Some options are:
1. Don't define the role (or disable it in your distro). ==> This
doesn't help us.
2. Have a predefined user with that role, and don't give those
credentials to the BMC admin. ==> This doesn't let us change the
credentials, and relies on the credentials remaining secret, which
violates best practices.
3. Have a special mode that makes additional operations available. ==>
This requires you to do one of:
(A) Permanently disable that special mode (like FieldMode or some other
process during the manufacturing process).
(B) Have a way turn the mode back on ... but how to do that securely so
the OEM or service can do it, but not the Admin. Maybe have the admin
install a certificate?
(C) Have a secret way to toggle the mode, which violates best practices.
4. Bake a special OemRep and ServiceRep certificate into the BMC
firmware image and use that to authenticate the ServiceRep. I tried to
explain in an IBM issue
(https://github.com/ibm-openbmc/dev/issues/1530), with the relevant
parts cut & pasted & edited here:
> To ensure the admin cannot assume the ServiceAgent and
ManufacturerRep roles, I think we would need to:
> * Have a certificate baked into the firmware image.
> * Use the baked-in certificate to validate the certificate the
ServiceAgent would have to uploads as part of their authentication. The
certificate is rejected if it wasn't signed by the baked-in certificate.
In this way, the service agent could gain access, but the Admin will not
> * Note the Admin will still have full control over the service
agent's account. In this way, the admin and service agent would have to
agree before the ServiceSystem privilege could be used to perform a
Despite the challenges, I think it is valuable to begin to create the
ServiceRep role, even if we don't have a good way to lock out the admin.
> Note: Currently we are using SpecialMode
> called Manufacturing mode, and certain activity can be done, when we
> are in this mode (i.e. Administrator role user in this mode will be
> able to do certain operations).
Thanks for explaining. I had not considered using a special mode for this.
> On 2/15/2020 1:51 AM, Joseph Reynolds wrote:
>> This is to propose two new Redfish roles:
>> The BMC Administrator should not have access to operations involving
>> the manufacturing process or servicing the host because these
>> operations can damage the system or cause unintended operation.
>> Examples of access needed:
>> 1. ServiceRep - Needs to access BMC operations to service the system,
>> such as re-enabling locked out field replaceable units (FRUs) after
>> replacing a defective unit.
>> 2. OemRep - Needs to access BMC operations to test the host system,
>> such as how the system responds to overheating.
>> I believe these roles are clearly distinct from role=Administrator or
>> any other role.
>> The roles should NOT have access to the BMC's configuration or user
>> management. For example, the BMC admin will be able to lock out any
>> service agent or OemRep using the regular user management functions.
>> Does anyone else need for these roles? If so, I will try to get them
>> into Redfish.
>> - Joseph
>> This topic was discussed briefly in the OpenBMC security working
>> group, 2019-11-27:
>> See also: https://github.com/ibm-openbmc/dev/issues/1529
More information about the openbmc