From: "Thomaiyar, Richard Marian" <richard.marian.thomaiyar@linux.intel.com>
To: Joseph Reynolds <jrey@linux.ibm.com>, openbmc <openbmc@lists.ozlabs.org>
Subject: Re: New Redfish roles for ServiceRep and OemRep
Date: Mon, 17 Feb 2020 12:59:48 +0530 [thread overview]
Message-ID: <6bb93465-ee23-ee6b-3d82-bfd944ea0706@linux.intel.com> (raw)
In-Reply-To: <a0c457af-88a5-08dd-91fa-357f47dfe93d@linux.ibm.com>
We need to make sure user account are not getting created in this role
by end-user. i.e. when creating a new user, these options must not be
provided. We need to have a separate way of selecting this role or
instead of not defining as role, we can add this as some mode in redfish.
Note: Currently we are using SpecialMode
(https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Security/SpecialMode.interface.yaml)
called Manufacturing mode, and certain activity can be done, when we are
in this mode (i.e. Administrator role user in this mode will be able to
do certain operations).
Regards,
Richard
On 2/15/2020 1:51 AM, Joseph Reynolds wrote:
> This is to propose two new Redfish roles:
>
> The BMC Administrator should not have access to operations involving
> the manufacturing process or servicing the host because these
> operations can damage the system or cause unintended operation.
>
> Examples of access needed:
> 1. ServiceRep - Needs to access BMC operations to service the system,
> such as re-enabling locked out field replaceable units (FRUs) after
> replacing a defective unit.
> 2. OemRep - Needs to access BMC operations to test the host system,
> such as how the system responds to overheating.
>
> I believe these roles are clearly distinct from role=Administrator or
> any other role.
>
> The roles should NOT have access to the BMC's configuration or user
> management. For example, the BMC admin will be able to lock out any
> service agent or OemRep using the regular user management functions.
>
> Does anyone else need for these roles? If so, I will try to get them
> into Redfish.
>
>
> - Joseph
>
> This topic was discussed briefly in the OpenBMC security working
> group, 2019-11-27:
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
>
> See also: https://github.com/ibm-openbmc/dev/issues/1529
>
next prev parent reply other threads:[~2020-02-17 7:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 20:21 New Redfish roles for ServiceRep and OemRep Joseph Reynolds
2020-02-17 7:29 ` Thomaiyar, Richard Marian [this message]
2020-02-18 0:48 ` Joseph Reynolds
2020-03-05 0:26 ` Joseph Reynolds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6bb93465-ee23-ee6b-3d82-bfd944ea0706@linux.intel.com \
--to=richard.marian.thomaiyar@linux.intel.com \
--cc=jrey@linux.ibm.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.