OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery]

On 14-Dec-2017 07:21 PM, Tom Joseph wrote:
>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?

Funny you should ask. We just had this conversation internally yesterday 
morning. I would propose that in this case, phosphor-user-manager would 
pass this information on to the network ipmi daemon that would handle 
storing the NV settings for "extra" user settings (because the notion of 
ipmi users is only used by the network daemon).

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

Again, the mapping would be done by the network ipmi daemon, which would 
also limit the number of ipmi users to 15.

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

I would say that IF somebody want to be so careless as to have an 
anonymous user, they could only use user ID 1 to hold it. But I think 
that allowing users to set user ID 1 to something else (and thus 
not following the spec EXACTLY) would be allowed. Really, in 2017, 
nobody should be using anonymous users anymore. But if they must have 
one, it would have to be a special case for the unix user -- something 
like ipmi-anonymous or something.

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

Just removing them from the ipmi group should trigger this sort of 
thing. However, removing a user from the ipmi group should also mark the 
password as expired to force the user to change it.

--Vernon

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