Discussion on openbmc issue #430

Discussion on openbmc issue #430

[tomjose]

[-- Attachment #1.1: Type: text/plain, Size: 2754 bytes --]

*Design and Implement Framework for IPMI backend*
------------------------------------------------------------------------------
The purpose of this is to come up with a mechanism to share providers 
between the host-ipmid and the rmcp-ipmid.
Also, update existing providers and host-ipmid to fit this framework. 
Demo of this story should be to use an existing
host-ipmid provider via the rmcp path.


*Registering Callback Routines:-*
-----------------------------------------------
1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
2) Scan for libraries that end with .so
3) Do a dlopen that would register the handlers for the callback routines.
The data that is currently registered for each command: Net Function, 
Command and Functor.

*Additional Metadata needed per command:-*
-----------------------------------------------------------------

*SessionLess Commands :-
*-------------------------------------*
*
This would mention whether the command can be executed without a 
session. For example
Get Channel Capabilities can be executed without a session.

*Minimum Privilege Required to Execute the command :-
*---------------------------------------------------------------------------------*

*This field would mention the minimum privilege of the session required 
to execute the
command. Before executing any command on a session, the command would be 
executed
only if the command privilege level is less than or equal to session 
privilege level.
The privilege levels are Administrator, Operator, User and Callback and OEM

*Firmware Firewalling :-
*--------------------------------*

**Channel Restriction :-
*------------------------------*

*The channel restriction can be applied if certain command needs to be 
restricted on System
Interface or LAN Interface.

The Get NetFn/ Command support can be used to get a list of commands 
that are supported
on a given channel. Implementation of these commands is not in the scope 
of this story.

*Command Firewalling:-
*--------------------------------*

*Configuration of Firmware Firewall capabilities is supported by 
commands that allow software to enable/disable individual commands.
The Firmware Firewall capability does not affect the operation of user 
and channel privileges.
That is, if a command requires Admin privilege level to be executed, it 
will still require Admin privilege if enabled by Firmware Firewall.

The different values that are supported for this field is:
a) Command is supported by default(can be configured(enabled or disabled)
b) Supported and cannot be configured( enable/disable is restricted)
c) Disabled by default but can be configured.

The firmware firewalling commands once supported would support the above 
operations.


Regards,
Tom

[-- Attachment #1.2: Type: text/html, Size: 3522 bytes --]

[-- Attachment #2: IPMI Provider Integration.pdf --]
[-- Type: application/pdf, Size: 34728 bytes --]

Re: Discussion on openbmc issue #430

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

Tom,

Thanks for sending this out to the broader community.

Few comments below...

On Fri, Aug 12, 2016 at 07:26:24PM +0530, tomjose wrote:
> *Registering Callback Routines:-*
> -----------------------------------------------
> 1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)

I would prefer we have a new directory '/usr/lib/phosphor-net-ipmid' for
the RMCP libraries.  We can create symlinks between the two repos as
appropriate.

The reason for this is two-fold:
   1) I suspect there will be some of the OEM commands that we will want
      to expose in-band only.
   2) There are commands that may want similarly excluded from the
      in-band path due to security concerns (even though we have the
      white-list support).

We might want to have a '/usr/lib/ipmid-providers' as the default
install location for all providers and then symlink into both
phosphor-net and phosphor-host as appropriate.

> 2) Scan for libraries that end with .so

Keep in mind you'll need to deal with versioned .so's as well.  We had
to add that support to host-ipmid recently.

> 3) Do a dlopen that would register the handlers for the callback routines.
> The data that is currently registered for each command: Net Function, 
> Command and Functor.

There are a few providers that register for dbus callbacks so they can
monitor signals.  We'll need to discuss a little more I think on what
the expectation is here.  Maybe the way we are doing dbus callbacks
isn't appropriate to begin with, or maybe the callbacks are for host
alerts and not needed in the network path?

> *SessionLess Commands :-
> *-------------------------------------*
> *
> This would mention whether the command can be executed without a 
> session. For example
> Get Channel Capabilities can be executed without a session.

How do we identify session-less commands?  Should this be an enhancement
to the registration API?

> *Minimum Privilege Required to Execute the command :-
> *---------------------------------------------------------------------------------*
> 
> *This field would mention the minimum privilege of the session required 
> to execute the
> command. Before executing any command on a session, the command would be 
> executed
> only if the command privilege level is less than or equal to session 
> privilege level.
> The privilege levels are Administrator, Operator, User and Callback and OEM

Are these privilege levels something intrinsic in IPMI or something you
came up with?

We plan to integrate the ipmi server into the same BMC user list as the
REST interface.  I think we need to identify these roles and then allow
unix-group membership to determine which commands can be ran.

We have a feature to be implemented for the REST interface to define
group membership requirements for dbus / REST calls as well.

How should providers specify these?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Discussion on openbmc issue #430

[tomjose]

Thanks Patrick for your feedack. I have mentioned my responses inline.

On Friday 12 August 2016 07:47 PM, Patrick Williams wrote:
> Tom,
>
> Thanks for sending this out to the broader community.
>
> Few comments below...
>
> On Fri, Aug 12, 2016 at 07:26:24PM +0530, tomjose wrote:
>> *Registering Callback Routines:-*
>> -----------------------------------------------
>> 1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
> I would prefer we have a new directory '/usr/lib/phosphor-net-ipmid' for
> the RMCP libraries.  We can create symlinks between the two repos as
> appropriate.
>
> The reason for this is two-fold:
>     1) I suspect there will be some of the OEM commands that we will want
>        to expose in-band only.
>     2) There are commands that may want similarly excluded from the
>        in-band path due to security concerns (even though we have the
>        white-list support).
>
> We might want to have a '/usr/lib/ipmid-providers' as the default
> install location for all providers and then symlink into both
> phosphor-net and phosphor-host as appropriate.
In the proposal, i had mentioned there is a provision to add channel 
restrictions to each command.
There are 3 variants available: execute on any channel, execute in-band 
only and execute on lan only.
The channel restriction would be evaluated before each command is executed.
I hope this would meet the same requirements.

>
>> 2) Scan for libraries that end with .so
> Keep in mind you'll need to deal with versioned .so's as well.  We had
> to add that support to host-ipmid recently.

Sure would take this into account while implementing.
>
>> 3) Do a dlopen that would register the handlers for the callback routines.
>> The data that is currently registered for each command: Net Function,
>> Command and Functor.
> There are a few providers that register for dbus callbacks so they can
> monitor signals.  We'll need to discuss a little more I think on what
> the expectation is here.  Maybe the way we are doing dbus callbacks
> isn't appropriate to begin with, or maybe the callbacks are for host
> alerts and not needed in the network path?
>
>> *SessionLess Commands :-
>> *-------------------------------------*
>> *
>> This would mention whether the command can be executed without a
>> session. For example
>> Get Channel Capabilities can be executed without a session.
> How do we identify session-less commands?  Should this be an enhancement
> to the registration API?
The session less commands are mentioned in the IPMI specification.
Examples are Get Channel Authentication Capabilites, Activate Session 
command etc.

>
>> *Minimum Privilege Required to Execute the command :-
>> *---------------------------------------------------------------------------------*
>>
>> *This field would mention the minimum privilege of the session required
>> to execute the
>> command. Before executing any command on a session, the command would be
>> executed
>> only if the command privilege level is less than or equal to session
>> privilege level.
>> The privilege levels are Administrator, Operator, User and Callback and OEM
> Are these privilege levels something intrinsic in IPMI or something you
> came up with?
>
> We plan to integrate the ipmi server into the same BMC user list as the
> REST interface.  I think we need to identify these roles and then allow
> unix-group membership to determine which commands can be ran.
>
> We have a feature to be implemented for the REST interface to define
> group membership requirements for dbus / REST calls as well.
>
> How should providers specify these?

The privilege levels attributed to each command is mentioned in the 
specification.
It is mentioned in the specification Table G-1,(Command Number 
Assignments and
Privilege Levels). The providers should provide these as registration 
parameters
when the callbacks are registered.
>

Re: Discussion on openbmc issue #430

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

On Tue, Aug 16, 2016 at 05:05:58PM +0530, tomjose wrote:
> 
> Thanks Patrick for your feedack. I have mentioned my responses inline.
> 
> On Friday 12 August 2016 07:47 PM, Patrick Williams wrote:
> > Tom,
> >
> > Thanks for sending this out to the broader community.
> >
> > Few comments below...
> >
> > On Fri, Aug 12, 2016 at 07:26:24PM +0530, tomjose wrote:
> >> *Registering Callback Routines:-*
> >> -----------------------------------------------
> >> 1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
> > I would prefer we have a new directory '/usr/lib/phosphor-net-ipmid' for
> > the RMCP libraries.  We can create symlinks between the two repos as
> > appropriate.
> >
> > The reason for this is two-fold:
> >     1) I suspect there will be some of the OEM commands that we will want
> >        to expose in-band only.
> >     2) There are commands that may want similarly excluded from the
> >        in-band path due to security concerns (even though we have the
> >        white-list support).
> >
> > We might want to have a '/usr/lib/ipmid-providers' as the default
> > install location for all providers and then symlink into both
> > phosphor-net and phosphor-host as appropriate.
> In the proposal, i had mentioned there is a provision to add channel 
> restrictions to each command.
> There are 3 variants available: execute on any channel, execute in-band 
> only and execute on lan only.
> The channel restriction would be evaluated before each command is executed.
> I hope this would meet the same requirements.

I would rather not codify that in the provider itself.  By using
symlinks we allow the system engineers to specify different behavior for
their system without having to modify code.  ie. through .bbappend
changes to the recipe.

> >> *SessionLess Commands :-
> >> *-------------------------------------*
> >> *
> >> This would mention whether the command can be executed without a
> >> session. For example
> >> Get Channel Capabilities can be executed without a session.
> > How do we identify session-less commands?  Should this be an enhancement
> > to the registration API?
> The session less commands are mentioned in the IPMI specification.
> Examples are Get Channel Authentication Capabilites, Activate Session 
> command etc.

I meant how are they identified by the provider?  You could want to
implement an OEM command that is session-less.  We need that identified
by the provider when they do registration?

> The privilege levels attributed to each command is mentioned in the 
> specification.
> It is mentioned in the specification Table G-1,(Command Number 
> Assignments and
> Privilege Levels). The providers should provide these as registration 
> parameters
> when the callbacks are registered.

Ok.  Those can be default groups.  Isn't there also a mechanism to
create custom groups with IPMI?  Since we plan to map IPMI users back to
PAM users, do we also need to map roles back to PAM groups?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]