* Proposal add PerformService privilege @ 2020-12-04 20:11 Joseph Reynolds 2020-12-09 18:25 ` Ed Tanous 0 siblings, 1 reply; 4+ messages in thread From: Joseph Reynolds @ 2020-12-04 20:11 UTC (permalink / raw) To: openbmc This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb. See https://redfishforum.com/thread/397/redfish-direction-update-eeproms As mentioned in the Redfish forum thread, the use case is that some OpenBMC use cases require isolating manufacturing and service functions away from the customer/admin (including updating FRU serial numbers, and updating a permanent MAC address), and this is a Redfish compatible way to do it. The work items would be like: - Add this OEM privilege to the base BMCWeb implementation. - Identify URIs that we need to be able to isolate away from customer/admins. Then modify the privilege mapping to require this privilege to PUT to those URIs. - Add this privilege to the Administrator role (but not Operator or ReadOnly). - Document how to isolate these operations. Specifically, remove this privilege from Administrator, and create a custom OEM role that has this privilege What do you think? - Joseph ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Proposal add PerformService privilege 2020-12-04 20:11 Proposal add PerformService privilege Joseph Reynolds @ 2020-12-09 18:25 ` Ed Tanous 2020-12-17 17:31 ` Joseph Reynolds 0 siblings, 1 reply; 4+ messages in thread From: Ed Tanous @ 2020-12-09 18:25 UTC (permalink / raw) To: Joseph Reynolds; +Cc: openbmc On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds <jrey@linux.ibm.com> wrote: > > This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb. > > See https://redfishforum.com/thread/397/redfish-direction-update-eeproms > As mentioned in the Redfish forum thread, the use case is that some > OpenBMC use cases require isolating manufacturing and service functions > away from the customer/admin (including updating FRU serial numbers, and > updating a permanent MAC address), and this is a Redfish compatible way > to do it. > > The work items would be like: > - Add this OEM privilege to the base BMCWeb implementation. Can you talk through how you would do this mechanically? Today, we rely on privilege registry (published from DMTF) to guide these roles and urls. Now that you've invented a new role, how do you plan on fitting that in? Will it be required for all systems? Will it be optional? Will it only apply to OEM schemas? > - Identify URIs that we need to be able to isolate away from > customer/admins. Then modify the privilege mapping to require this > privilege to PUT to those URIs. What URLs have what privileges is already defined by DMTF in the base privilege registry. What you're talking about would require a customizable privilege registry, which definitely needs some significant thought, as the current privileges mechanisms in bmcweb are very static today. Just "customizable privileges registry" is probably a design on its own, and would likely need to land before adding OEM privilege levels. > - Add this privilege to the Administrator role (but not Operator or > ReadOnly). If we're adding this privilege to the Administrator role, how does it differ from ConfigureManager role? > - Document how to isolate these operations. Specifically, remove this > privilege from Administrator, and create a custom OEM role that has this > privilege > > What do you think? I think we've got a couple designs that would need to land ahead of this before we'd have the infrastructure and documentation to build something like this. The designs I see coming before this are: Static PrivilegeRegistry implementation modifiable/dynamic Per-URI privilege registry implementation modifiable/dynamic Per-property privilege registry implementation OemOpenBMCPerformService registry added. > - Joseph > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Proposal add PerformService privilege 2020-12-09 18:25 ` Ed Tanous @ 2020-12-17 17:31 ` Joseph Reynolds 2020-12-17 17:48 ` Ed Tanous 0 siblings, 1 reply; 4+ messages in thread From: Joseph Reynolds @ 2020-12-17 17:31 UTC (permalink / raw) To: Ed Tanous; +Cc: openbmc On 12/9/20 12:25 PM, Ed Tanous wrote: > On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds<jrey@linux.ibm.com> wrote: >> This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb. >> >> Seehttps://redfishforum.com/thread/397/redfish-direction-update-eeproms >> As mentioned in the Redfish forum thread, the use case is that some >> OpenBMC use cases require isolating manufacturing and service functions >> away from the customer/admin (including updating FRU serial numbers, and >> updating a permanent MAC address), and this is a Redfish compatible way >> to do it. >> >> The work items would be like: >> - Add this OEM privilege to the base BMCWeb implementation. > Can you talk through how you would do this mechanically? Today, we > rely on privilege registry (published from DMTF) to guide these roles > and urls. Now that you've invented a new role, how do you plan on > fitting that in? Will it be required for all systems? Will it be > optional? Will it only apply to OEM schemas? Note: Around the same this this email was sent, we discussed this in the Security working group 2020-12-09, with minutes here: https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI Here are the basics of the low level design: #. Enhance redfish-core/include/privileges.hpp -- add the new "OEMPerformService" privilege. #. Enhance redfish-core/lib/roles.hpp -- add OEMPerformService to thje existing Administrator role && add the new "ServiceAgent" role #ifdef's by a new config option. #. Modify the privilege map for individual operations as appropriate to require the OEMPerformService privilege. However, you are correct that this may not be the best approach. See below. >> - Identify URIs that we need to be able to isolate away from >> customer/admins. Then modify the privilege mapping to require this >> privilege to PUT to those URIs. > What URLs have what privileges is already defined by DMTF in the base > privilege registry. What you're talking about would require a > customizable privilege registry, which definitely needs some > significant thought, as the current privileges mechanisms in bmcweb > are very static today. Just "customizable privileges registry" is > probably a design on its own, and would likely need to land before > adding OEM privilege levels. That makes sense. However, some URIs are outside the scope of Redfish including: - The URI named by the Assembly BinaryDataURI property. - Various manufacturer-specific REST APIs. >> - Add this privilege to the Administrator role (but not Operator or >> ReadOnly). > If we're adding this privilege to the Administrator role, how does it > differ from ConfigureManager role? The main idea is that the Redfish-defined Administrator role *by default* has all Redfish standard privileges. But I don't think this applies to OEM privileges, so I am re-thinking this point. My point remains that I need a separate OEMPerformService privilege; having this privilege enables my Enterprise Server system to remove this privilege from admins, and give it to my service agents. I'm not sure if I understood or answered your question. >> - Document how to isolate these operations. Specifically, remove this >> privilege from Administrator, and create a custom OEM role that has this >> privilege >> >> What do you think? > I think we've got a couple designs that would need to land ahead of > this before we'd have the infrastructure and documentation to build > something like this. > > > The designs I see coming before this are: > Static PrivilegeRegistry implementation > modifiable/dynamic Per-URI privilege registry implementation > modifiable/dynamic Per-property privilege registry implementation > OemOpenBMCPerformService registry added. Yes, we discussed this in the workgroup call. Specifically, we discussed making a better privilege registry implementation. Redfish (DSP0266) defines an operation-to-privilege mapping and is represented as a Privilege Registry. BMCWeb currently implements the Redfish authorization model as a mapping from URI -> HTTP verb -> privileges. The privilege overrides are hard-coded in C++ in each operation handler. If I understood this correctly, the first step is to enhance BMCWeb to directly use the published Redfish PrivilegeRegistry (such as Redfish_1.0.4_PrivilegeRegistry.json). Elements includes: - Add new build step to convert the PrivilegeRegistry file into C++ code that implements the authority checking. The main ideas are: a downstream implementation can easily customize their PrivilegeRegistry and it will automatically build into the code. And performing the authority check must be fast and efficient. - The set of privileges is part of the Privilege Registry, and its implementation should be enhanced accordingly. - Handling the basic "privilege and and or syntax clauses" is straightforward. Handling Resource URI overrides seems straightforward. Handling property overrides I need to think about more. And I am not aware that BMCWeb has any Subordinate overrides - All the overrides can be build-time configurable; I do not need dynamic changes to the privilege registry. I plan think about this over break,and have a proposal in January 2021. Thanks! Joseph >> - Joseph >> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Proposal add PerformService privilege 2020-12-17 17:31 ` Joseph Reynolds @ 2020-12-17 17:48 ` Ed Tanous 0 siblings, 0 replies; 4+ messages in thread From: Ed Tanous @ 2020-12-17 17:48 UTC (permalink / raw) To: Joseph Reynolds; +Cc: openbmc On Thu, Dec 17, 2020 at 9:31 AM Joseph Reynolds <jrey@linux.ibm.com> wrote: > > On 12/9/20 12:25 PM, Ed Tanous wrote: > > On Fri, Dec 4, 2020 at 12:13 PM Joseph Reynolds<jrey@linux.ibm.com> wrote: > >> This is a proposal to add an OemOpenBMCPerformService privilege to BMCWeb. > >> > >> Seehttps://redfishforum.com/thread/397/redfish-direction-update-eeproms > >> As mentioned in the Redfish forum thread, the use case is that some > >> OpenBMC use cases require isolating manufacturing and service functions > >> away from the customer/admin (including updating FRU serial numbers, and > >> updating a permanent MAC address), and this is a Redfish compatible way > >> to do it. > >> > >> The work items would be like: > >> - Add this OEM privilege to the base BMCWeb implementation. > > Can you talk through how you would do this mechanically? Today, we > > rely on privilege registry (published from DMTF) to guide these roles > > and urls. Now that you've invented a new role, how do you plan on > > fitting that in? Will it be required for all systems? Will it be > > optional? Will it only apply to OEM schemas? > > Note: Around the same this this email was sent, we discussed this in the > Security working group 2020-12-09, with minutes here: > https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI > > Here are the basics of the low level design: > #. Enhance redfish-core/include/privileges.hpp -- add the new > "OEMPerformService" privilege. > #. Enhance redfish-core/lib/roles.hpp -- add OEMPerformService to thje > existing Administrator role && add the new "ServiceAgent" role #ifdef's > by a new config option. > #. Modify the privilege map for individual operations as appropriate to > require the OEMPerformService privilege. > > However, you are correct that this may not be the best approach. See below. > > > >> - Identify URIs that we need to be able to isolate away from > >> customer/admins. Then modify the privilege mapping to require this > >> privilege to PUT to those URIs. > > What URLs have what privileges is already defined by DMTF in the base > > privilege registry. What you're talking about would require a > > customizable privilege registry, which definitely needs some > > significant thought, as the current privileges mechanisms in bmcweb > > are very static today. Just "customizable privileges registry" is > > probably a design on its own, and would likely need to land before > > adding OEM privilege levels. > > That makes sense. However, some URIs are outside the scope of Redfish > including: > - The URI named by the Assembly BinaryDataURI property. Do we support this yet? It seems like the BinaryDataURI would follow the same permissions as the equivalent property/resource within redfish. With that said, > - Various manufacturer-specific REST APIs. This confuses me a little. Manufacturer specific rest APIs will have their own privilege/authorization systems, similar to how IPMI has its own privilege system. While they're related, the other manufacturer rest APIs can apply whatever permissions they like. Within redfish, they would appear as something like "OEM<Company API name>Privilege" and be orthogonal to Redfish privileges, as it's a totally separate API; > > >> - Add this privilege to the Administrator role (but not Operator or > >> ReadOnly). > > If we're adding this privilege to the Administrator role, how does it > > differ from ConfigureManager role? > > The main idea is that the Redfish-defined Administrator role *by > default* has all Redfish standard privileges. But I don't think this > applies to OEM privileges, so I am re-thinking this point. > My point remains that I need a separate OEMPerformService privilege; > having this privilege enables my Enterprise Server system to remove this > privilege from admins, and give it to my service agents. > I'm not sure if I understood or answered your question. "I need to create a new privilege and apply it to certain endpoints" is a use case covered by Redfish and well understood in a fully functioning PrivilegeRegistry implementation. We just don't have a configurable privilege registry setup yet. > > >> - Document how to isolate these operations. Specifically, remove this > >> privilege from Administrator, and create a custom OEM role that has this > >> privilege > >> > >> What do you think? > > I think we've got a couple designs that would need to land ahead of > > this before we'd have the infrastructure and documentation to build > > something like this. > > > > > > The designs I see coming before this are: > > Static PrivilegeRegistry implementation > > modifiable/dynamic Per-URI privilege registry implementation > > modifiable/dynamic Per-property privilege registry implementation > > OemOpenBMCPerformService registry added. > > Yes, we discussed this in the workgroup call. > > Specifically, we discussed making a better privilege registry > implementation. Redfish (DSP0266) defines an operation-to-privilege > mapping and is represented as a Privilege Registry. > > BMCWeb currently implements the Redfish authorization model as a mapping > from URI -> HTTP verb -> privileges. The privilege overrides are > hard-coded in C++ in each operation handler. > > If I understood this correctly, the first step is to enhance BMCWeb to > directly use the published Redfish PrivilegeRegistry (such as > Redfish_1.0.4_PrivilegeRegistry.json). Elements includes: > - Add new build step to convert the PrivilegeRegistry file into C++ code > that implements the authority checking. The main ideas are: a > downstream implementation can easily customize their PrivilegeRegistry > and it will automatically build into the code. And performing the > authority check must be fast and efficient. Sounds exactly right. When we first wrote the existing privileges system, we actually had a script that automated this, but that was on an old machine that's now defunct, so it's probably gone and certainly out of date. With that said, it was a trivial amount of code. > - The set of privileges is part of the Privilege Registry, and its > implementation should be enhanced accordingly. > - Handling the basic "privilege and and or syntax clauses" is > straightforward. The existing privileges system is already set up to handle and/or clauses per the redfish schema, you just need to generate the correct set of bracketed C++ structures (same as you see in the Node class) for it to read in. > Handling Resource URI overrides seems > straightforward. Handling property overrides I need to think about > more. And I am not aware that BMCWeb has any Subordinate overrides Yep, the per property stuff gets hard, as we don't really do "per property" code. In the next few years of Redfish development, I suspect this problem will come up more and more and we'll need to start breaking out individual properties into their own little world. > - All the overrides can be build-time configurable; I do not need > dynamic changes to the privilege registry. Sounds good. > > I plan think about this over break,and have a proposal in January 2021. > > Thanks! > Joseph > > >> - Joseph > >> > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-17 17:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-04 20:11 Proposal add PerformService privilege Joseph Reynolds 2020-12-09 18:25 ` Ed Tanous 2020-12-17 17:31 ` Joseph Reynolds 2020-12-17 17:48 ` Ed Tanous
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.