Isolate service privileges
jrey at linux.ibm.com
Wed Jun 3 09:59:40 AEST 2020
Summary: This presents a requirement to isolate service functions and a
use case where the administrator does not have service privileges. The
motivation for a new service representative role is presented along with
extensions to the Redfish privilege model. Additional changes needed to
make this work are described.
A service representative is a person authorized to perform service on a
computer system, typically a high-end system, serviced by an independent
organization, and working under a service agreement. An example service
call is to power off a PCIe slot, physically replace a defective FRU
device, then use BMC functions to update FRU data like serial number or
MAC address, mark error logs entries as handled, etc. The service rep
needs access to enhanced service tools that allow deeper diagnostics and
Why do we need to lock out the administrator from sensitive service
functions? Updating FRU data can cause incorrect operations when done
improperly. Marking error log entries as "handled" without following
repair procedures can cause incorrect diagnosis, unnecessary repair
actions, and cost more time. These are examples of BMC functions that
the service rep must perform, and BMC admins must not be allowed to perform.
To be clear, by default, the administrator will have full privileges
including service privileges. There will be a new option (like an image
feature) to remove service privileges from the administrator role and
achieve the effect described in this note.
The main pieces are:
- Create a new ServiceRep role and service privilege. These would be
available in the base implementation.
- Require the service privilege to perform sensitive service
operations. This affects the Redfish operation-to-privilege mapping and
its implementation in BMCWeb.
- Have a build-time option to either allow the admin to perform service
operations or lock them out.
When the Administrator is locked out of service privileges:
- The admin maintains control of user management, for example, disabling
service rep accounts.
- The admin must not be allowed to escalate to the ServiceRep role. For
example, they could create a ServiceRep account for themselves and then
try to use it to perform service operations. Examples of how the system
can prevent this escalation:
+ The admin must not be allowed to create or change any account to
have the ServiceRep role, or
+ Using the service privilege must require additional authentication.
- The admin must not be allowed to access the command shell as the root
user. For example, the admin account must not be root, and if SSH is
available, the admin user must not have `sudo` authority or `su`
credentials. Root can subvert access controls and perform service
1. I will propose a new ServiceRep Role and related PerformService
privilege in a followup email.
2. The mechanism to authenticate a service rep in a way an admin cannot
use is outside the scope of this design. We had discussed a
certificate-based approach in the security working group. I believe the
other items in this email have merit even without this piece.
3. To prevent the admin from escalating to the service account, we can
have a new image feature to restrict use of the ServiceRep role (so the
admin cannot create or change existing accounts with this role) and then
pre-create the "service" account.
4. As a prerequisite, I would like to move the project away from the
default "root" login to a new "admin" account. The Administrator
accounts would then be able to use the `sudo` command to become root. A
new image feature could disallow the admin from `sudo` access.
All of these taken together will achieve the goal of isolating BMC
service functions. I plan to start with the ServiceRep piece, first
gathering comments from the OpenBMC community, then presenting it to
Redfish. Next priority is creating an admin account and disallowing
root logins. I plan to send details for each piece as I go, and welcome
More information about the openbmc