OpenBMC community telecon - 11/27 Agenda
Vernon Mauery
vernon.mauery at linux.intel.com
Wed Dec 6 11:49:31 AEDT 2017
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.
>
More information about the openbmc
mailing list