Isolate service privileges

[Joseph Reynolds]

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.

Motivation

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

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

Next steps

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

- Joseph