|
|
Post by josephreynolds1 on Feb 5, 2020 20:12:08 GMT
The Redfish spec for DSP8011 version 2019.4 > Redfish_1.0.4_PrivilegeRegistry > ManagerAccountCollection changed the privilege required for GET (as in GET /redfish/v1/AccountService/Accounts/). The 1.0.3 spec required either the ConfigureUsers or the ConfigureManager privilege. The 1.0.4 spec requires only the Login privilege.
I understand this change allows non-admin users to use REST discoverability to locate their own ManagerAccount (as in being able to GET all the URIs leading up to /redfish/v1/AccountService/Accounts/USER, where USER is the name of the account the agent is using to access the service). However, this change also allows the user to enumerate Redfish accounts as described in CWE-213 and CWE-200 (details below). That can help an authenticated attacker learn the name of an admin account which they can then chain with other attacks to access an admin account.
I am advocating to change this part of the spec back to the old way. I prefer the previous approach where the ManagerAccountCollection URI was handled as an exception to the REST discoverability model. That is, it is okay with me to require users to handle access to their own account specially, and not be able to discover their own account. Maybe the Session object could have a link to the user's Account object? { "Links": { "Account": { ... "/redfish/v1/AccountService/Accounts/USER" } } }
- Joseph
Details: CWE-200 indicates that exposing usernames helps attackers, and CWE-213 indicates the design exposes this information deliberately, albeit only to authenticated users. Taken together, these seem to indicate that interfaces ought to not expose usernames on purpose. Certainly, you may debate that point. I searched the CWE database for items to support this view, but did not find a more direct formulation of: Only privileges users such as admins should be allowed to enumerate all user accounts.)
|
|
|
|
Post by josephreynolds1 on Feb 11, 2020 0:37:45 GMT
We are discussing this in the OpenBMC email list and OpenBMC security working group. For example, see an archived email here: lists.ozlabs.org/pipermail/openbmc/2020-February/020468.htmlI prefer require the ConfigureUsers or ConfigureManager privilege to GET the ManagerAccountCollection.... An alternate idea is to require only the Login privilege, but respond only with the accounts the user has access to. For example, ReadOnly user would see only their own account, while an admin user would see all accounts. We would probably want another @extendedmessage like "No all members were shown. Only those members you have access to were shown." --> The advantage of this design is that regular users have REST discoverability of their own account. A disadvantage is the additional complexity. |
|
|
|
Post by rthomaiy on Feb 11, 2020 4:26:12 GMT
Yes, from security point of it, other than self user account, rest of the user account should be displayed only to configureUsers / configureManager privilege and not for Login privileged users. Exposing this information to login user can cause a DOS attack (by entering the wrong password and trying to lock the account).
I agree with joseph, we may need to update / understand in detail about why the change has been proposed.
|
|
|
|
Post by j2hilland on Feb 11, 2020 19:19:19 GMT
When we changed it, we assumed that the Login privilege would only pertain to the current account and not allow viewing of other accounts. It looks like that description was left off in the Privilege Registry. DMTF needs to update the description of Login privilege to ensure that this only allows getting records from either AccountCollection or SessionCollection that pertain to the current account. Right now it reads like anyone can access the information and that was not the intention.
|
|
|
|
Post by josephreynolds1 on Feb 11, 2020 20:32:36 GMT
|
|
|
|
Post by rthomaiy on Feb 25, 2021 5:14:10 GMT
|
|
|
|
Post by AMI_Mani on Jun 14, 2023 8:08:30 GMT
Hi, Do we have any update on changing privilege from login for managercollection? In redfish.dmtf.org/registries/Redfish_1.4.0_PrivilegeRegistry.jsonEntity": "ManagerCollection",
"OperationMap": {
"GET": [
{
"Privilege": [
"Login"
]
}
], Again changing privilege to configuremanager will not allow readonly, operator to list their accounts alone in Managercollection get response? Readonly user getting If this is discussed in different thread or conclusion arrived, please provide me the link Thanks, Mani |
|
|
|
Post by mraineri on Jun 14, 2023 12:25:33 GMT
The forum is still of the opinion that "Login" is correct here. The reason being is without that specified, a client is unable to locate their user account via HATEOAS practices. There's no mechanism in the privilege registry to specify selective pruning of collection members based on privileges; I also suspect that sort of definition would create additional complexity and bloat to the already large registry.
However, the specification was updated several releases ago to specify that services are allowed to modify responses to remove links the user does not have privilege to access. We have the following text in the "Redfish service operation-to-privilege mapping" clause:
> A service may perform additional checks based on the identity of the user and remove data from responses. For example, a service might restrict access for non-administrative users to only access their own ManagerAccount , Session , and EventDestination resources.
So, in this case, a service that requires hiding other user accounts is free to remove collection members from responses based on the client's privilege and only show a link to their own user account.
|
|
