Re: OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery <vernon.mauery@linux.intel.com>]

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.
2. How to manage the permissions groups (is there a PAM group mechanism?)
3. How to create users (call adduser?)
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?


--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.
>