Re: OpenBMC community telecon - 11/27 Agenda

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

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.