Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop <bradleyb@fuzziesquirrel.com>]

On Tue, 2017-12-05 at 16:49 -0800, Vernon Mauery wrote:
> On 04-Dec-2017 05:02 PM, Vernon Mauery wrote:
> > On 04-Dec-2017 05:06 PM, Brad Bishop wrote:
> > > multi configuration images / runtime configurability
> > > user management
> > > secure coding guidelines
> > > 
> > > —————————
> > > Monday, 10:00pm EDT
> > > 888-426-6840
> > > password: 85891389
> > 
> > For the discussion on user management.
> > 
> > Overview:
> > 1. User management is done via PAM.
> > 2. If IPMI is being used, PAM loads the pam_ipmi.so password
> > module.
> >  a. pam_ipmi.so intercepts password changes and saves the password
> >     for IPMI-enabled users to a file that can be read at a later
> > time
> >     to initiate an RMCP+ session. (encrypted or obfuscated with
> > a      
> > per-BMC key so no passwords are written directly in flash.)
> >  b. pam_ipmi.so implements a method to decrypt passwords and
> > provide
> >     them to host-ipmi (for test password command) and net-ipmi (for
> >     session initiation)
> > 3. If a user is not enabled for IPMI, their password will not be
> > saved
> >  in the ipmi database, and thus must be reset if/when that user
> > gains
> >  IPMI capability.
> > 4. If a user loses IPMI capability, their password is reset to
> > force a
> >  password change so their password is secure again.
> > 5. Capabilities is done via unix groups
> >  a. Groups like ipmi, webserver, redfish, ssh, sol can provide
> > login      
> > or 'channel' access.
> >  b. Groups like user-manager, media, power, sensor, etc., can
> > provide
> >     fine-grained access for various capabilities. Providers
> > of      
> > capabilities should check to see that accessors (users) have
> > the      
> > required permission.
> > 6. Admin-defined 'super-groups'
> >  a. Provide a set of pre-defined groups of capabilities that can be
> >     assigned to users: Admin, User, Operator or similar that each
> > have
> >     groups associated with them.
> >  b. Changes to groups via APIs can make sure that if a user
> > is      
> > assigned to a 'super-group' will stay assigned to the sub-groups
> >  c. Changes made to users via manual commands may override API
> > groups
> 
> Items yet to be decided:
> 1. How providers of services export the service/permission pairs so
> the 
> user manager can manage the permission groups.

My thought was a bitbake class (like useradd.bbclass) could probably
get us here but I haven't thought about it beyond that.

> 2. How to manage the permissions groups (is there a PAM group
> mechanism?)

Could a custom PAM module best meet this need?  There is pam_listfile
for 'normal' groups but for this group-of-groups concept I'd guess
there isn't anything like this out there already.

> 3. How to create users (call adduser?)

This seems like a reasonable starting point.  If later someone speaks
up that it doesn't meet their needs we can always revisit and refactor
then imho.

> 4. Do we force users to have different passwords for RMCP+ and other 
> logins because RMCP+ passwords are insecurely stored? Or is this a 
> policy thing that we allow system administrators to choose?

A third choice could be same passwords + no policy.

I would vote for a choice (so policy) but you can let your own needs
drive your work here some.  For example you could implement same
passwords + no policy if that met your cuurrent needs, as long as
someone can later come in and add the policy and implement the other
side of it with relative ease.

> 
> 
> --Vernon
> 
> > 
> > Methods:
> >   1. CREATE_USER
> >       Privilege-required: USER-MANAGER
> >       Args:
> >           UserName - STRING (16 bytes only - else role change to
> > IPMI can't be done)
> >           Password - Byte Array (Max of 20 bytes if IPMID is
> > chosen. For
> >                      others can send more bytes, but change role to
> > IPMI will
> >                      request password again under 20 bytes)
> >           Roles - STRING with comma separated
> >       Return:
> >           SUCCESS ERR_USERNAME_EXIST ERR_PASSWORD_FAILS
> > ERR_ROLE_FAILS
> >           ERR_PASSWORD_ROLE_FAIL ERR_NO_RESOURCE ERR_UNKNOWN
> >           ERR_AUTHORIZATION_FAIL
> > 
> >   2. DELETE_USER
> >       Privilege-required: USER-MANAGER
> >       Args:
> >           UserName - STRING
> >       Return:
> >           SUCCESS ERR_USERNAME_NOT_EXIST ERR_UNKNOWN
> > ERR_AUTHORIZATION_FAIL
> > 
> >   3. CHANGE ROLE / CHANGE_PASSWORD (OTHERS)
> >       Privilege-required: USER-MANAGER
> >       Args:
> >           UserName - STRING
> >           New Password (if changed) - Byte Array
> >           New Role (if changed) - Array of STRING
> >       Return:
> >           SUCCESS ERR_USERNAME_NOT_EXIST ERR_UNKNOWN
> > ERR_AUTHORIZATION_FAIL
> >           ERR_PASSWORD_FAILS ERR_PASSWORD_ROLE_FAIL ERR_NO_RESOURCE
> > 
> >   4. CHANGE_PASSWORD (SELF)
> >       Privilege-required: Any Valid user
> >       Args:
> >           New Password - Byte Array
> >       Return:
> >           SUCCESS ERR_PASSWORD_FAILS ERR_PASSWORD_ROLE_FAIL
> > ERR_UNKNOWN
> > 
> >   5. LIST_USER_DETAILS
> >       Privilege-required: USER-MANAGER
> >       Args:
> >           NULL
> >       Return:
> >           Array of:
> >               USER_NAME (String)
> >               ROLES (String)
> > 
> > Signals:
> >   1. UPDATED_USER_SIGNAL
> >       Args:
> >           UserName of updated user
> >           UpdateType:
> >               Role changed / User Deleted / User created /
> > Password 
> > Changed etc.
> >