|
|
Post by josephreynolds1 on Jun 4, 2020 2:47:35 GMT
I am interested in isolating BMC service privileges so we could satisfy a use case to remove them from the Administrator role and only service reps can perform service. The default use case would give all privileges to the admin. I've motivated this requirement in an email to the OpenBMC community [1], and pitched a new ServiceRep role and privilege in a separate thread [2].
I think a discussion with both the OpenBMC community and the Redfish forum would be productive. Specifically, I would like to get ideas for optional role-to-privilege mappings mentioned in the the email.
- Joseph
|
|
|
|
Post by rthomaiy on Jun 21, 2020 6:45:03 GMT
I didn't see any further comments on Joseph, and hence thought of extending the use case here.
Till now, we have configured components in the factory, and deployed in the customer end, but as the trend changes, where customers are offered platform as a service, and offered to buy some features at later stage, we need to update / write certain components on the deployed system. In order to provide this functionality we may need to write new MAC, change Part model etc. on a deployed system. This requires a special privilege, which is not allowed to be created in normal case, or a specific user account can have his privilege extended to this on special condition.
or assume where a permanent log needs to be cleared and reset (which will not even happen in normal reset to defaults).
if use case is acceptable, then we can further discuss on the privilege, it's mapping and operation.
1. Say, ConfigureUser account is not allowed to create a user with say "ConfigServiceRep" privilege (New privilege which is in request), but ConfigServiceRep can do some clear / write operation, which ConfigManager or any other existing privilege accounts can do
2. How to create a user with ConfigPrivilege, or any existing account can have incremental privilege support based on certain conditions (may be certificate based authentication ? key or any special mode etc.).
3. ConfigServiceRep must be different from ConfigManager / ConfigComponents (i.e. not allowed to create or configure components), but a side role, who can do service level operation on the account. Say, this privilege user can do reset to defaults, but can't create new user accounts.
Awaiting for comments
|
|
|
|
Post by josephreynolds1 on Jun 21, 2020 15:39:58 GMT
I understand our use cases are very similar (between IBM Enterprise systems and the Intel use case you described). We also have a use case for deleting security logs, which we are formulating under NIST 800-88 "Guidelines for Media Sanitization" - csrc.nist.gov/publications/detail/sp/800-88/rev-1/final. I don't think even a hypothetical SecurityAdmin role should be allowed to delete security logs. I am still trying to figure out the right way to perform a secure erase of the BMC's media. However, I have not yet written about that. To address your numbered points: 1. You are correct. The Redfish spec might need to be updated to say something like, "When applicable, the ConfigureUsers privilege does not apply to users with the ServiceRep role." The intent is the admin cannot escalate to ServiceRep. 2. My idea is to have a special pre-configured "service" account such that (A) the admin cannot modify it, delete it, or get into it in any other way, and (B) the authorized service rep (person) can authenticate to it. I plan to use gerrit.openbmc-project.xyz/c/openbmc/docs/+/33847/1/designs/admin-account.md#71 to pre-create a "service" account in the meta-openpower or meta-ibm layer. 3a. I think we are agreed that the proposed ConfigServiceRep privilege (I called it the PerformService privilege, but it is the same) must be different from the existing ConfigureManager and ConfigureComponents privileges. 3b. That's exactly the use case we have: We want the service rep to be able to "recover" the admin account (where "recover" means something like: reset the admin account password). But we don't want the service rep to have the ConfigureUsers privilege in general. This is tricky. I believe there are a couple of use cases here. For example, a forgetful admin needs to call service because of a forgotten password. On the other end of the spectrum, a computer system that processes sensitive data might need to comply with PCI-DSS specs, and lock out the service rep from resetting the admin password. (I have some ideas here that are not fully developed.) |
|
|
|
Post by josephreynolds1 on Dec 1, 2020 19:40:58 GMT
|
|
