OpenBMC community telecon - 11/27 Agenda
Vernon Mauery
vernon.mauery at linux.intel.com
Tue Dec 5 12:02:05 AEDT 2017
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
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