OpenBMC community telecon - 11/27 Agenda

[Tom Joseph]

Hey Vernon,

There are a few points about IPMI User accounts where more details are 
needed.

a) IPMI User configuration(password/privilege) is done for a per channel 
basis. How do you plan to implement where the same user would have 
different passwords/privileges?

b) IPMI user accounts are mapped to User ID, and all user account 
related commands refer to user id to identify an account. I hope we need 
to consider that when we design.

c) User ID 1 account has no user name. Would we support this account?

d) Can you add API's to map enable/disable IPMI accounts, so that IPMI 
user accounts can be enabled/disabled by retaining all other properties?

Regards,

Tom


On Wednesday 06 December 2017 06:19 AM, 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.
> 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.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171214/ca6de036/attachment.html>