OpenBMC community telecon - 11/27 Agenda

OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

multi configuration images / runtime configurability
user management
secure coding guidelines

—————————
Monday, 10:00pm EDT
888-426-6840
password: 85891389

Re: OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery]

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.     

Re: OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery]

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

Re: OpenBMC community telecon - 11/27 Agenda

[Tom Joseph]

[-- Attachment #1: Type: text/plain, Size: 5583 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 8325 bytes --]

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

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

On Tue, 2017-12-05 at 16:49 -0800, 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.

My thought was a bitbake class (like useradd.bbclass) could probably
get us here but I haven't thought about it beyond that.

> 2. How to manage the permissions groups (is there a PAM group
> mechanism?)

Could a custom PAM module best meet this need?  There is pam_listfile
for 'normal' groups but for this group-of-groups concept I'd guess
there isn't anything like this out there already.

> 3. How to create users (call adduser?)

This seems like a reasonable starting point.  If later someone speaks
up that it doesn't meet their needs we can always revisit and refactor
then imho.

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

A third choice could be same passwords + no policy.

I would vote for a choice (so policy) but you can let your own needs
drive your work here some.  For example you could implement same
passwords + no policy if that met your cuurrent needs, as long as
someone can later come in and add the policy and implement the other
side of it with relative ease.

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

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:

Hi Vernon

Really appreciate you putting this together - thanks.  I do have a
couple comments/questions.

> 
> For the discussion on user management.
> 
> Overview:
> 1. User management is done via PAM.

Are there any aspects of user management that are done outside of PAM?
I only ask this because your writeup feels like a good start on a
README somewhere.  To that end, would it make sense to frame this from
the perspective of different actors attempting to add function?  For
example:

 If you want to implement a service that authenticates a user:
   - do v
   - do w

 If you want to implement a service that adds users to a user database:
   - do x

 If you want to implement a service that adds users to a group:
   - do y

 If you want to implement a service that authorizes a user:
   - do z

 etc, and then the IPMI specifics would just be adhering to this
framework.

I could have these bullet points all wrong.  This was just meant as a
straw-man for a more general document that can guide people looking to
add this type of function later.

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

I'm not understanding why this is needed.  Couldn't we simply remove
the password entry from the IPMI backend when the group membership
changes?  Is this an artifact of how PAM works or do we think we need
it for a more fundamental reason?

> 5. Capabilities is done via unix groups
>    a. Groups like ipmi, webserver, redfish, ssh, sol can provide
> login 
>       or 'channel' access.

I wonder if a per-channel (or service in PAM speak?) pam_listfile
account entry can get us here.

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

pam_listfile might work here too, only this would global across all PAM
services?

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

Do we intend to also allow the contained subgroups to be
changed/configured for the on the BMC dynamically?  For example could
you remove the 'sensor' group from the Operator group (assuming that by
default sensor group is included in the Operator group).

>    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

This all seemed pretty straightforward until I got to #6.  It seems
like it is definitely required but I'm wondering if it could be staged
in later somehow?

> 
> 
> Methods:

Do we need similar APIs for groups?

>     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

Can we use the xyz.openbmc_project.Object.Delete interface for this? 
The thinking was that a common Delete interface might make DBus<->UI
implementations easier.  This is the same motivation behind asking for
the org.freedesktop interfaces below.

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

I thought the intent was to strictly use PAM for this.  In what
scenario do we need a DBus API for this?

>     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

Same question as #3.

> 
>     5. LIST_USER_DETAILS
>         Privilege-required: USER-MANAGER
>         Args:
>             NULL
>         Return:
>             Array of:
>                 USER_NAME (String)
>                 ROLES (String)

Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for
this?

> 
> Signals:
>     1. UPDATED_USER_SIGNAL
>         Args:
>             UserName of updated user
>             UpdateType:
>                 Role changed / User Deleted / User created / Password

Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?

> Changed etc.     

Re: OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery]

On 18-Dec-2017 01:07 PM, Brad Bishop wrote:
>On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:
>
>Hi Vernon
>
>Really appreciate you putting this together - thanks.  I do have a
>couple comments/questions.
>
>>
>> For the discussion on user management.
>>
>> Overview:
>> 1. User management is done via PAM.
>
>Are there any aspects of user management that are done outside of PAM?

Yes. It turns out that IPMI management with multiple LAN channels throws 
a wrench in things, so it may be that IPMI need to do some of its user 
management separately (like determining what privileges a user gets on a 
particular channel). There may be other stuff like this, so it might be 
helpful to define a 'hook' or something that says if a user is a member 
of group X, you must notify group X when you want to change stuff.

>I only ask this because your writeup feels like a good start on a
>README somewhere.  To that end, would it make sense to frame this from
>the perspective of different actors attempting to add function?  For
>example:
>
> If you want to implement a service that authenticates a user:
>   - do v
>   - do w
>
> If you want to implement a service that adds users to a user database:
>   - do x
>
> If you want to implement a service that adds users to a group:
>   - do y
>
> If you want to implement a service that authorizes a user:
>   - do z
>
> etc, and then the IPMI specifics would just be adhering to this
>framework.
>
>I could have these bullet points all wrong.  This was just meant as a
>straw-man for a more general document that can guide people looking to
>add this type of function later.

Yes, this sort of writeup as a README would be a good idea. Not just an 
API, but a practical usage guide.

>> 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.
>
>I'm not understanding why this is needed.  Couldn't we simply remove
>the password entry from the IPMI backend when the group membership
>changes?  Is this an artifact of how PAM works or do we think we need
>it for a more fundamental reason?

If the password is ever saved in the IPMI password database, it is best 
to assume it is no longer a secret. If you really want your password 
secure, it should be changed.

>> 5. Capabilities is done via unix groups
>>    a. Groups like ipmi, webserver, redfish, ssh, sol can provide
>> login
>>       or 'channel' access.
>
>I wonder if a per-channel (or service in PAM speak?) pam_listfile
>account entry can get us here.

Sure, that could be a pattern we follow. I would have to dig deeper to 
see if it buys us anything that plain-old unix groups would not provide.

>>    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.
>
>pam_listfile might work here too, only this would global across all PAM
>services?

Once again, I am not entirely sure what this would buy over just using 
unix groups. We need to walk through some more usage scenarios like you 
have above.

>> 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.
>
>Do we intend to also allow the contained subgroups to be
>changed/configured for the on the BMC dynamically?  For example could
>you remove the 'sensor' group from the Operator group (assuming that by
>default sensor group is included in the Operator group).

Ideally, yes, a system admin could change what capabilities each group 
allowed (like removing sensor capabilities from the Operator group), but 
to start with, just having a way to define the defaults at built time 
would be a good target.

>>    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
>
>This all seemed pretty straightforward until I got to #6.  It seems
>like it is definitely required but I'm wondering if it could be staged
>in later somehow?

Yes. Let's just start with defining a way to define defaults. This 
should be done using a yocto mechanism that allows developers of openbmc 
to override at build time (maybe on a platform basis?). This makes the 
original defaults less important (so not all of the contributors need to 
fully agree on what constitutes reasonable defaults).

>>
>>
>> Methods:
>
>Do we need similar APIs for groups?

Likely. But to start with, maybe we can skip that part. To start with, 
the list of groups (and their associated capabilities) will be fixed at 
build time.

>>     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
>
>Can we use the xyz.openbmc_project.Object.Delete interface for this?
>The thinking was that a common Delete interface might make DBus<->UI
>implementations easier.  This is the same motivation behind asking for
>the org.freedesktop interfaces below.

I am fine with using generic interfaces as long as they fit the bill. 
Deleting a user seems like it should be straight-forward enough that 
this would work well.

>>
>>     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
>>
>
>I thought the intent was to strictly use PAM for this.  In what
>scenario do we need a DBus API for this?

For managing groups, this will have to be done outside of PAM. PAM 
doesn't know how to change /etc/group. So we will have to provide some 
central mechanism (probably in the phosphor-user-manager) to host the 
group management API.

>>     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
>
>Same question as #3.

You are right. Passwords should not go over DBus. Things that change 
passwords should use PAM directly.

>>
>>     5. LIST_USER_DETAILS
>>         Privilege-required: USER-MANAGER
>>         Args:
>>             NULL
>>         Return:
>>             Array of:
>>                 USER_NAME (String)
>>                 ROLES (String)
>
>Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for
>this?

Yes.

>>
>> Signals:
>>     1. UPDATED_USER_SIGNAL
>>         Args:
>>             UserName of updated user
>>             UpdateType:
>>                 Role changed / User Deleted / User created / Password
>
>Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?

Yes.

--Vernon

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

> On Dec 18, 2017, at 5:39 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 18-Dec-2017 01:07 PM, Brad Bishop wrote:
>> On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:
>> 
>> Hi Vernon
>> 
>> Really appreciate you putting this together - thanks.  I do have a
>> couple comments/questions.
>> 
>>> 
>>> For the discussion on user management.
>>> 
>>> Overview:
>>> 1. User management is done via PAM.
>> 
>> Are there any aspects of user management that are done outside of PAM?
> 
> Yes. It turns out that IPMI management with multiple LAN channels throws a wrench in things, so it may be that IPMI need to do some of its user management separately (like determining what privileges a user gets on a particular channel).

Could creating a group per channel on the BMC at runtime make this
simpler?

> There may be other stuff like this, so it might be helpful to define a 'hook' or something that says if a user is a member of group X, you must notify group X when you want to change stuff.
> 
>> I only ask this because your writeup feels like a good start on a
>> README somewhere.  To that end, would it make sense to frame this from
>> the perspective of different actors attempting to add function?  For
>> example:
>> 
>> If you want to implement a service that authenticates a user:
>>  - do v
>>  - do w
>> 
>> If you want to implement a service that adds users to a user database:
>>  - do x
>> 
>> If you want to implement a service that adds users to a group:
>>  - do y
>> 
>> If you want to implement a service that authorizes a user:
>>  - do z
>> 
>> etc, and then the IPMI specifics would just be adhering to this
>> framework.
>> 
>> I could have these bullet points all wrong.  This was just meant as a
>> straw-man for a more general document that can guide people looking to
>> add this type of function later.
> 
> Yes, this sort of writeup as a README would be a good idea. Not just an API, but a practical usage guide.
> 
>>> 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.
>> 
>> I'm not understanding why this is needed.  Couldn't we simply remove
>> the password entry from the IPMI backend when the group membership
>> changes?  Is this an artifact of how PAM works or do we think we need
>> it for a more fundamental reason?
> 
> If the password is ever saved in the IPMI password database, it is best to assume it is no longer a secret. If you really want your password secure, it should be changed.

ok.

> 
>>> 5. Capabilities is done via unix groups
>>>   a. Groups like ipmi, webserver, redfish, ssh, sol can provide
>>> login
>>>      or 'channel' access.
>> 
>> I wonder if a per-channel (or service in PAM speak?) pam_listfile
>> account entry can get us here.
> 
> Sure, that could be a pattern we follow. I would have to dig deeper to see if it buys us anything that plain-old unix groups would not provide.
> 
>>>   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.
>> 
>> pam_listfile might work here too, only this would global across all PAM
>> services?
> 
> Once again, I am not entirely sure what this would buy over just using unix groups. We need to walk through some more usage scenarios like you have above.
> 

I wasn’t intending to propose something extra - this was just the
result of my brief research on how to authorize users based on group
membership with PAM.

I’ve never written any programs that use PAM so I could be way off
in the weeds here.  I guess my question would be what other way can
we do it?


>>> 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.
>> 
>> Do we intend to also allow the contained subgroups to be
>> changed/configured for the on the BMC dynamically?  For example could
>> you remove the 'sensor' group from the Operator group (assuming that by
>> default sensor group is included in the Operator group).
> 
> Ideally, yes, a system admin could change what capabilities each group allowed (like removing sensor capabilities from the Operator group), but to start with, just having a way to define the defaults at built time would be a good target.
> 
>>>   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
>> 
>> This all seemed pretty straightforward until I got to #6.  It seems
>> like it is definitely required but I'm wondering if it could be staged
>> in later somehow?
> 
> Yes. Let's just start with defining a way to define defaults. This should be done using a yocto mechanism that allows developers of openbmc to override at build time (maybe on a platform basis?). This makes the original defaults less important (so not all of the contributors need to fully agree on what constitutes reasonable defaults).

Sounds good.  Lets say you have an operator group on platform X with
sensors and an operator group on platform Y without sensors.  How would
you authorize the user?

> 
>>> 
>>> 
>>> Methods:
>> 
>> Do we need similar APIs for groups?
> 
> Likely. But to start with, maybe we can skip that part. To start with, the list of groups (and their associated capabilities) will be fixed at build time.

Sounds good.

> 
>>>    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
>> 
>> Can we use the xyz.openbmc_project.Object.Delete interface for this?
>> The thinking was that a common Delete interface might make DBus<->UI
>> implementations easier.  This is the same motivation behind asking for
>> the org.freedesktop interfaces below.
> 
> I am fine with using generic interfaces as long as they fit the bill. Deleting a user seems like it should be straight-forward enough that this would work well.
> 
>>> 
>>>    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
>>> 
>> 
>> I thought the intent was to strictly use PAM for this.  In what
>> scenario do we need a DBus API for this?
> 
> For managing groups, this will have to be done outside of PAM. PAM doesn't know how to change /etc/group. So we will have to provide some central mechanism (probably in the phosphor-user-manager) to host the group management API.
> 
>>>    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
>> 
>> Same question as #3.
> 
> You are right. Passwords should not go over DBus. Things that change passwords should use PAM directly.
> 
>>> 
>>>    5. LIST_USER_DETAILS
>>>        Privilege-required: USER-MANAGER
>>>        Args:
>>>            NULL
>>>        Return:
>>>            Array of:
>>>                USER_NAME (String)
>>>                ROLES (String)
>> 
>> Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for
>> this?
> 
> Yes.
> 
>>> 
>>> Signals:
>>>    1. UPDATED_USER_SIGNAL
>>>        Args:
>>>            UserName of updated user
>>>            UpdateType:
>>>                Role changed / User Deleted / User created / Password
>> 
>> Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?
> 
> Yes.
> 
> --Vernon

RE: OpenBMC community telecon - 11/27 Agenda

[Michael.E.Brown]

I fully support using PAM for user and password management. This is the method we use in our product and it has been fairly successful.

However, the one thing I would like to point out is that you want to keep your "Linux users" separate from your IPMI/Web/etc users, and you want to keep your Linux groups separate from the IPMI/web/etc groups. You configure PAM specifically to have separate PAM configurations for IPMI/web/etc that is different, for example pam_listfile for ipmi and pam_unix for logins.

This works well except for the following:
1) PAM api is synchronous. You have to do some lifting to ensure everything works well for async event loop programs or for multi-threaded programs.
2) For allowing actual Linux shell logins using IPMI/web usernames.
	This intersection point becomes a problem. What we do in our product may or may not be a satisfactory solution. What we do in our product is have a single Linux user "racuser" and an NSS library. All SSH or local logins map the actual username back to this racuser user. PAM is used to check the actual user password. The PAM module then sets an environment variable with the user details and correct permissions the user has. The reason this works is that we have a restricted shell where the user is not allowed to reset environment variables. All of the command line utilities check the permissions when deciding if the logged in user should be able to perform an action, and log with the user details given in the environment. This is unlikely to be a satisfactory answer for openbmc where the user can get full shell access. However, using linux containers, we may be able to use a user container to do this same mapping.

Other notes:
	Once you use PAM, you can then configure AD/LDAP and other by simply changing the PAM configuration. We use a custom PAM module that handles AD and LDAP, however I believe the existing open source PAM modules for AD/LDAP would work well here. Once you support AD and/or LDAP, you have to have a method of mapping directory groups to specific permissions on the local BMC, and that can be challenging. The most straightforward method is to statically configure group names, however it is also the least flexible from a large organization perspective. This is something that could be discussed/designed after base PAM support is all enabled, though.

--
Michael


-----Original Message-----
From: openbmc [mailto:openbmc-bounces+michael.e.brown=dell.com@lists.ozlabs.org] On Behalf Of Brad Bishop
Sent: Monday, December 18, 2017 6:32 PM
To: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: OpenBMC <openbmc@lists.ozlabs.org>; Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
Subject: Re: OpenBMC community telecon - 11/27 Agenda


> On Dec 18, 2017, at 5:39 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 18-Dec-2017 01:07 PM, Brad Bishop wrote:
>> On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:
>> 
>> Hi Vernon
>> 
>> Really appreciate you putting this together - thanks.  I do have a 
>> couple comments/questions.
>> 
>>> 
>>> For the discussion on user management.
>>> 
>>> Overview:
>>> 1. User management is done via PAM.
>> 
>> Are there any aspects of user management that are done outside of PAM?
> 
> Yes. It turns out that IPMI management with multiple LAN channels throws a wrench in things, so it may be that IPMI need to do some of its user management separately (like determining what privileges a user gets on a particular channel).

Could creating a group per channel on the BMC at runtime make this simpler?

> There may be other stuff like this, so it might be helpful to define a 'hook' or something that says if a user is a member of group X, you must notify group X when you want to change stuff.
> 
>> I only ask this because your writeup feels like a good start on a 
>> README somewhere.  To that end, would it make sense to frame this 
>> from the perspective of different actors attempting to add function?  
>> For
>> example:
>> 
>> If you want to implement a service that authenticates a user:
>>  - do v
>>  - do w
>> 
>> If you want to implement a service that adds users to a user database:
>>  - do x
>> 
>> If you want to implement a service that adds users to a group:
>>  - do y
>> 
>> If you want to implement a service that authorizes a user:
>>  - do z
>> 
>> etc, and then the IPMI specifics would just be adhering to this 
>> framework.
>> 
>> I could have these bullet points all wrong.  This was just meant as a 
>> straw-man for a more general document that can guide people looking 
>> to add this type of function later.
> 
> Yes, this sort of writeup as a README would be a good idea. Not just an API, but a practical usage guide.
> 
>>> 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.
>> 
>> I'm not understanding why this is needed.  Couldn't we simply remove 
>> the password entry from the IPMI backend when the group membership 
>> changes?  Is this an artifact of how PAM works or do we think we need 
>> it for a more fundamental reason?
> 
> If the password is ever saved in the IPMI password database, it is best to assume it is no longer a secret. If you really want your password secure, it should be changed.

ok.

> 
>>> 5. Capabilities is done via unix groups
>>>   a. Groups like ipmi, webserver, redfish, ssh, sol can provide 
>>> login
>>>      or 'channel' access.
>> 
>> I wonder if a per-channel (or service in PAM speak?) pam_listfile 
>> account entry can get us here.
> 
> Sure, that could be a pattern we follow. I would have to dig deeper to see if it buys us anything that plain-old unix groups would not provide.
> 
>>>   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.
>> 
>> pam_listfile might work here too, only this would global across all 
>> PAM services?
> 
> Once again, I am not entirely sure what this would buy over just using unix groups. We need to walk through some more usage scenarios like you have above.
> 

I wasn’t intending to propose something extra - this was just the result of my brief research on how to authorize users based on group membership with PAM.

I’ve never written any programs that use PAM so I could be way off in the weeds here.  I guess my question would be what other way can we do it?


>>> 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.
>> 
>> Do we intend to also allow the contained subgroups to be 
>> changed/configured for the on the BMC dynamically?  For example could 
>> you remove the 'sensor' group from the Operator group (assuming that 
>> by default sensor group is included in the Operator group).
> 
> Ideally, yes, a system admin could change what capabilities each group allowed (like removing sensor capabilities from the Operator group), but to start with, just having a way to define the defaults at built time would be a good target.
> 
>>>   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
>> 
>> This all seemed pretty straightforward until I got to #6.  It seems 
>> like it is definitely required but I'm wondering if it could be 
>> staged in later somehow?
> 
> Yes. Let's just start with defining a way to define defaults. This should be done using a yocto mechanism that allows developers of openbmc to override at build time (maybe on a platform basis?). This makes the original defaults less important (so not all of the contributors need to fully agree on what constitutes reasonable defaults).

Sounds good.  Lets say you have an operator group on platform X with sensors and an operator group on platform Y without sensors.  How would you authorize the user?

> 
>>> 
>>> 
>>> Methods:
>> 
>> Do we need similar APIs for groups?
> 
> Likely. But to start with, maybe we can skip that part. To start with, the list of groups (and their associated capabilities) will be fixed at build time.

Sounds good.

> 
>>>    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
>> 
>> Can we use the xyz.openbmc_project.Object.Delete interface for this?
>> The thinking was that a common Delete interface might make DBus<->UI 
>> implementations easier.  This is the same motivation behind asking 
>> for the org.freedesktop interfaces below.
> 
> I am fine with using generic interfaces as long as they fit the bill. Deleting a user seems like it should be straight-forward enough that this would work well.
> 
>>> 
>>>    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
>>> 
>> 
>> I thought the intent was to strictly use PAM for this.  In what 
>> scenario do we need a DBus API for this?
> 
> For managing groups, this will have to be done outside of PAM. PAM doesn't know how to change /etc/group. So we will have to provide some central mechanism (probably in the phosphor-user-manager) to host the group management API.
> 
>>>    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
>> 
>> Same question as #3.
> 
> You are right. Passwords should not go over DBus. Things that change passwords should use PAM directly.
> 
>>> 
>>>    5. LIST_USER_DETAILS
>>>        Privilege-required: USER-MANAGER
>>>        Args:
>>>            NULL
>>>        Return:
>>>            Array of:
>>>                USER_NAME (String)
>>>                ROLES (String)
>> 
>> Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for 
>> this?
> 
> Yes.
> 
>>> 
>>> Signals:
>>>    1. UPDATED_USER_SIGNAL
>>>        Args:
>>>            UserName of updated user
>>>            UpdateType:
>>>                Role changed / User Deleted / User created / Password
>> 
>> Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?
> 
> Yes.
> 
> --Vernon

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

Hi Michael

Thanks for the info!


> On Dec 20, 2017, at 3:26 PM, <Michael.E.Brown@dell.com> <Michael.E.Brown@dell.com> wrote:
> 
> I fully support using PAM for user and password management. This is the method we use in our product and it has been fairly successful.
> 
> However, the one thing I would like to point out is that you want to keep your "Linux users" separate from your IPMI/Web/etc users, and you want to keep your Linux groups separate from the IPMI/web/etc groups.

Can you elaborate on why and/or call out any specific issues
you’ve had with this approach?

> You configure PAM specifically to have separate PAM configurations for IPMI/web/etc that is different, for example pam_listfile for ipmi and pam_unix for logins.
> 
> This works well except for the following:
> 1) PAM api is synchronous. You have to do some lifting to ensure everything works well for async event loop programs or for multi-threaded programs.
> 2) For allowing actual Linux shell logins using IPMI/web usernames.
> 	This intersection point becomes a problem. What we do in our product may or may not be a satisfactory solution. What we do in our product is have a single Linux user "racuser" and an NSS library. All SSH or local logins map the actual username back to this racuser user. PAM is used to check the actual user password. The PAM module then sets an environment variable with the user details and correct permissions the user has. The reason this works is that we have a restricted shell where the user is not allowed to reset environment variables. All of the command line utilities check the permissions when deciding if the logged in user should be able to perform an action, and log with the user details given in the environment. This is unlikely to be a satisfactory answer for openbmc where the user can get full shell access. However, using linux containers, we may be able to use a user container to do this same mapping.
> 
> Other notes:
> 	Once you use PAM, you can then configure AD/LDAP and other by simply changing the PAM configuration. We use a custom PAM module that handles AD and LDAP, however I believe the existing open source PAM modules for AD/LDAP would work well here. Once you support AD and/or LDAP, you have to have a method of mapping directory groups to specific permissions on the local BMC, and that can be challenging. The most straightforward method is to statically configure group names, however it is also the least flexible from a large organization perspective. This is something that could be discussed/designed after base PAM support is all enabled, though.
> 
> --
> Michael
> 
> 
> -----Original Message-----
> From: openbmc [mailto:openbmc-bounces+michael.e.brown=dell.com@lists.ozlabs.org] On Behalf Of Brad Bishop
> Sent: Monday, December 18, 2017 6:32 PM
> To: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: OpenBMC <openbmc@lists.ozlabs.org>; Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
> Subject: Re: OpenBMC community telecon - 11/27 Agenda
> 
> 
>> On Dec 18, 2017, at 5:39 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>> 
>> On 18-Dec-2017 01:07 PM, Brad Bishop wrote:
>>> On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:
>>> 
>>> Hi Vernon
>>> 
>>> Really appreciate you putting this together - thanks.  I do have a 
>>> couple comments/questions.
>>> 
>>>> 
>>>> For the discussion on user management.
>>>> 
>>>> Overview:
>>>> 1. User management is done via PAM.
>>> 
>>> Are there any aspects of user management that are done outside of PAM?
>> 
>> Yes. It turns out that IPMI management with multiple LAN channels throws a wrench in things, so it may be that IPMI need to do some of its user management separately (like determining what privileges a user gets on a particular channel).
> 
> Could creating a group per channel on the BMC at runtime make this simpler?
> 
>> There may be other stuff like this, so it might be helpful to define a 'hook' or something that says if a user is a member of group X, you must notify group X when you want to change stuff.
>> 
>>> I only ask this because your writeup feels like a good start on a 
>>> README somewhere.  To that end, would it make sense to frame this 
>>> from the perspective of different actors attempting to add function?  
>>> For
>>> example:
>>> 
>>> If you want to implement a service that authenticates a user:
>>> - do v
>>> - do w
>>> 
>>> If you want to implement a service that adds users to a user database:
>>> - do x
>>> 
>>> If you want to implement a service that adds users to a group:
>>> - do y
>>> 
>>> If you want to implement a service that authorizes a user:
>>> - do z
>>> 
>>> etc, and then the IPMI specifics would just be adhering to this 
>>> framework.
>>> 
>>> I could have these bullet points all wrong.  This was just meant as a 
>>> straw-man for a more general document that can guide people looking 
>>> to add this type of function later.
>> 
>> Yes, this sort of writeup as a README would be a good idea. Not just an API, but a practical usage guide.
>> 
>>>> 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.
>>> 
>>> I'm not understanding why this is needed.  Couldn't we simply remove 
>>> the password entry from the IPMI backend when the group membership 
>>> changes?  Is this an artifact of how PAM works or do we think we need 
>>> it for a more fundamental reason?
>> 
>> If the password is ever saved in the IPMI password database, it is best to assume it is no longer a secret. If you really want your password secure, it should be changed.
> 
> ok.
> 
>> 
>>>> 5. Capabilities is done via unix groups
>>>>  a. Groups like ipmi, webserver, redfish, ssh, sol can provide 
>>>> login
>>>>     or 'channel' access.
>>> 
>>> I wonder if a per-channel (or service in PAM speak?) pam_listfile 
>>> account entry can get us here.
>> 
>> Sure, that could be a pattern we follow. I would have to dig deeper to see if it buys us anything that plain-old unix groups would not provide.
>> 
>>>>  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.
>>> 
>>> pam_listfile might work here too, only this would global across all 
>>> PAM services?
>> 
>> Once again, I am not entirely sure what this would buy over just using unix groups. We need to walk through some more usage scenarios like you have above.
>> 
> 
> I wasn’t intending to propose something extra - this was just the result of my brief research on how to authorize users based on group membership with PAM.
> 
> I’ve never written any programs that use PAM so I could be way off in the weeds here.  I guess my question would be what other way can we do it?
> 
> 
>>>> 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.
>>> 
>>> Do we intend to also allow the contained subgroups to be 
>>> changed/configured for the on the BMC dynamically?  For example could 
>>> you remove the 'sensor' group from the Operator group (assuming that 
>>> by default sensor group is included in the Operator group).
>> 
>> Ideally, yes, a system admin could change what capabilities each group allowed (like removing sensor capabilities from the Operator group), but to start with, just having a way to define the defaults at built time would be a good target.
>> 
>>>>  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
>>> 
>>> This all seemed pretty straightforward until I got to #6.  It seems 
>>> like it is definitely required but I'm wondering if it could be 
>>> staged in later somehow?
>> 
>> Yes. Let's just start with defining a way to define defaults. This should be done using a yocto mechanism that allows developers of openbmc to override at build time (maybe on a platform basis?). This makes the original defaults less important (so not all of the contributors need to fully agree on what constitutes reasonable defaults).
> 
> Sounds good.  Lets say you have an operator group on platform X with sensors and an operator group on platform Y without sensors.  How would you authorize the user?
> 
>> 
>>>> 
>>>> 
>>>> Methods:
>>> 
>>> Do we need similar APIs for groups?
>> 
>> Likely. But to start with, maybe we can skip that part. To start with, the list of groups (and their associated capabilities) will be fixed at build time.
> 
> Sounds good.
> 
>> 
>>>>   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
>>> 
>>> Can we use the xyz.openbmc_project.Object.Delete interface for this?
>>> The thinking was that a common Delete interface might make DBus<->UI 
>>> implementations easier.  This is the same motivation behind asking 
>>> for the org.freedesktop interfaces below.
>> 
>> I am fine with using generic interfaces as long as they fit the bill. Deleting a user seems like it should be straight-forward enough that this would work well.
>> 
>>>> 
>>>>   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
>>>> 
>>> 
>>> I thought the intent was to strictly use PAM for this.  In what 
>>> scenario do we need a DBus API for this?
>> 
>> For managing groups, this will have to be done outside of PAM. PAM doesn't know how to change /etc/group. So we will have to provide some central mechanism (probably in the phosphor-user-manager) to host the group management API.
>> 
>>>>   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
>>> 
>>> Same question as #3.
>> 
>> You are right. Passwords should not go over DBus. Things that change passwords should use PAM directly.
>> 
>>>> 
>>>>   5. LIST_USER_DETAILS
>>>>       Privilege-required: USER-MANAGER
>>>>       Args:
>>>>           NULL
>>>>       Return:
>>>>           Array of:
>>>>               USER_NAME (String)
>>>>               ROLES (String)
>>> 
>>> Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for 
>>> this?
>> 
>> Yes.
>> 
>>>> 
>>>> Signals:
>>>>   1. UPDATED_USER_SIGNAL
>>>>       Args:
>>>>           UserName of updated user
>>>>           UpdateType:
>>>>               Role changed / User Deleted / User created / Password
>>> 
>>> Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?
>> 
>> Yes.
>> 
>> --Vernon

RE: OpenBMC community telecon - 11/27 Agenda

[Michael.E.Brown]

The main issue is one of security. And I realize here that openbmc has a different security model than our product, but here goes:

The "ipmi/web/etc" users are "attacker controlled", if you consider the end-user the adversary and are trying to protect the internal functioning of the product. That may sound a bit off, but the main thing here is that we don't want to allow the user(/administrator) to do something that would break the product or allow an insecure situation. In our product we now have all of our internal daemons running as non-root and a separate user account for each daemon. For example: the "powerd" daemon runs as the "power" user and "power" group. That linux user has permissions to the /dev entries it needs to function, but does not have access to things like KVM or other infrastructure or hardware that it doesn’t need. Since we allow "ssh" logins to a (minimalistic) shell (either racadm or a smash compatible clp), that represents an attack surface. If the user were able to create user called "power" that is a linux user and an ipmi/web user and they logged into the box as that 'power' user, it would be have the same permissions as our power daemon. We try to lock down the default shells for non-privileged users but this would represent a possible entry point.

Thus, separate your linux users from your frontend users.

This is the same concept that postgres, apache, or most other daemons that have "users" do.

The next issue that you run into is permissions mapping. You have to have a way to map permissions between AD/LDAP groups and the groups you use internally. That's sort of a separate discussion, but it can get complex. Fortunately, it can be relatively well-contained in your pam module if done properly.

--
Michael

-----Original Message-----
From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com] 
Sent: Wednesday, December 20, 2017 2:30 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>
Cc: Vernon Mauery <vernon.mauery@linux.intel.com>; openbmc@lists.ozlabs.org; richard.marian.thomaiyar@linux.intel.com
Subject: Re: OpenBMC community telecon - 11/27 Agenda

Hi Michael

Thanks for the info!


> On Dec 20, 2017, at 3:26 PM, <Michael.E.Brown@dell.com> <Michael.E.Brown@dell.com> wrote:
> 
> I fully support using PAM for user and password management. This is the method we use in our product and it has been fairly successful.
> 
> However, the one thing I would like to point out is that you want to keep your "Linux users" separate from your IPMI/Web/etc users, and you want to keep your Linux groups separate from the IPMI/web/etc groups.

Can you elaborate on why and/or call out any specific issues you’ve had with this approach?

> You configure PAM specifically to have separate PAM configurations for IPMI/web/etc that is different, for example pam_listfile for ipmi and pam_unix for logins.
> 
> This works well except for the following:
> 1) PAM api is synchronous. You have to do some lifting to ensure everything works well for async event loop programs or for multi-threaded programs.
> 2) For allowing actual Linux shell logins using IPMI/web usernames.
> 	This intersection point becomes a problem. What we do in our product may or may not be a satisfactory solution. What we do in our product is have a single Linux user "racuser" and an NSS library. All SSH or local logins map the actual username back to this racuser user. PAM is used to check the actual user password. The PAM module then sets an environment variable with the user details and correct permissions the user has. The reason this works is that we have a restricted shell where the user is not allowed to reset environment variables. All of the command line utilities check the permissions when deciding if the logged in user should be able to perform an action, and log with the user details given in the environment. This is unlikely to be a satisfactory answer for openbmc where the user can get full shell access. However, using linux containers, we may be able to use a user container to do this same mapping.
> 
> Other notes:
> 	Once you use PAM, you can then configure AD/LDAP and other by simply changing the PAM configuration. We use a custom PAM module that handles AD and LDAP, however I believe the existing open source PAM modules for AD/LDAP would work well here. Once you support AD and/or LDAP, you have to have a method of mapping directory groups to specific permissions on the local BMC, and that can be challenging. The most straightforward method is to statically configure group names, however it is also the least flexible from a large organization perspective. This is something that could be discussed/designed after base PAM support is all enabled, though.
> 
> --
> Michael
> 
> 
> -----Original Message-----
> From: openbmc 
> [mailto:openbmc-bounces+michael.e.brown=dell.com@lists.ozlabs.org] On 
> Behalf Of Brad Bishop
> Sent: Monday, December 18, 2017 6:32 PM
> To: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: OpenBMC <openbmc@lists.ozlabs.org>; Richard Marian Thomaiyar 
> <richard.marian.thomaiyar@linux.intel.com>
> Subject: Re: OpenBMC community telecon - 11/27 Agenda
> 
> 
>> On Dec 18, 2017, at 5:39 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>> 
>> On 18-Dec-2017 01:07 PM, Brad Bishop wrote:
>>> On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:
>>> 
>>> Hi Vernon
>>> 
>>> Really appreciate you putting this together - thanks.  I do have a 
>>> couple comments/questions.
>>> 
>>>> 
>>>> For the discussion on user management.
>>>> 
>>>> Overview:
>>>> 1. User management is done via PAM.
>>> 
>>> Are there any aspects of user management that are done outside of PAM?
>> 
>> Yes. It turns out that IPMI management with multiple LAN channels throws a wrench in things, so it may be that IPMI need to do some of its user management separately (like determining what privileges a user gets on a particular channel).
> 
> Could creating a group per channel on the BMC at runtime make this simpler?
> 
>> There may be other stuff like this, so it might be helpful to define a 'hook' or something that says if a user is a member of group X, you must notify group X when you want to change stuff.
>> 
>>> I only ask this because your writeup feels like a good start on a 
>>> README somewhere.  To that end, would it make sense to frame this 
>>> from the perspective of different actors attempting to add function?
>>> For
>>> example:
>>> 
>>> If you want to implement a service that authenticates a user:
>>> - do v
>>> - do w
>>> 
>>> If you want to implement a service that adds users to a user database:
>>> - do x
>>> 
>>> If you want to implement a service that adds users to a group:
>>> - do y
>>> 
>>> If you want to implement a service that authorizes a user:
>>> - do z
>>> 
>>> etc, and then the IPMI specifics would just be adhering to this 
>>> framework.
>>> 
>>> I could have these bullet points all wrong.  This was just meant as 
>>> a straw-man for a more general document that can guide people 
>>> looking to add this type of function later.
>> 
>> Yes, this sort of writeup as a README would be a good idea. Not just an API, but a practical usage guide.
>> 
>>>> 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.
>>> 
>>> I'm not understanding why this is needed.  Couldn't we simply remove 
>>> the password entry from the IPMI backend when the group membership 
>>> changes?  Is this an artifact of how PAM works or do we think we 
>>> need it for a more fundamental reason?
>> 
>> If the password is ever saved in the IPMI password database, it is best to assume it is no longer a secret. If you really want your password secure, it should be changed.
> 
> ok.
> 
>> 
>>>> 5. Capabilities is done via unix groups  a. Groups like ipmi, 
>>>> webserver, redfish, ssh, sol can provide login
>>>>     or 'channel' access.
>>> 
>>> I wonder if a per-channel (or service in PAM speak?) pam_listfile 
>>> account entry can get us here.
>> 
>> Sure, that could be a pattern we follow. I would have to dig deeper to see if it buys us anything that plain-old unix groups would not provide.
>> 
>>>>  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.
>>> 
>>> pam_listfile might work here too, only this would global across all 
>>> PAM services?
>> 
>> Once again, I am not entirely sure what this would buy over just using unix groups. We need to walk through some more usage scenarios like you have above.
>> 
> 
> I wasn’t intending to propose something extra - this was just the result of my brief research on how to authorize users based on group membership with PAM.
> 
> I’ve never written any programs that use PAM so I could be way off in the weeds here.  I guess my question would be what other way can we do it?
> 
> 
>>>> 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.
>>> 
>>> Do we intend to also allow the contained subgroups to be 
>>> changed/configured for the on the BMC dynamically?  For example 
>>> could you remove the 'sensor' group from the Operator group 
>>> (assuming that by default sensor group is included in the Operator group).
>> 
>> Ideally, yes, a system admin could change what capabilities each group allowed (like removing sensor capabilities from the Operator group), but to start with, just having a way to define the defaults at built time would be a good target.
>> 
>>>>  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
>>> 
>>> This all seemed pretty straightforward until I got to #6.  It seems 
>>> like it is definitely required but I'm wondering if it could be 
>>> staged in later somehow?
>> 
>> Yes. Let's just start with defining a way to define defaults. This should be done using a yocto mechanism that allows developers of openbmc to override at build time (maybe on a platform basis?). This makes the original defaults less important (so not all of the contributors need to fully agree on what constitutes reasonable defaults).
> 
> Sounds good.  Lets say you have an operator group on platform X with sensors and an operator group on platform Y without sensors.  How would you authorize the user?
> 
>> 
>>>> 
>>>> 
>>>> Methods:
>>> 
>>> Do we need similar APIs for groups?
>> 
>> Likely. But to start with, maybe we can skip that part. To start with, the list of groups (and their associated capabilities) will be fixed at build time.
> 
> Sounds good.
> 
>> 
>>>>   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
>>> 
>>> Can we use the xyz.openbmc_project.Object.Delete interface for this?
>>> The thinking was that a common Delete interface might make DBus<->UI 
>>> implementations easier.  This is the same motivation behind asking 
>>> for the org.freedesktop interfaces below.
>> 
>> I am fine with using generic interfaces as long as they fit the bill. Deleting a user seems like it should be straight-forward enough that this would work well.
>> 
>>>> 
>>>>   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
>>>> 
>>> 
>>> I thought the intent was to strictly use PAM for this.  In what 
>>> scenario do we need a DBus API for this?
>> 
>> For managing groups, this will have to be done outside of PAM. PAM doesn't know how to change /etc/group. So we will have to provide some central mechanism (probably in the phosphor-user-manager) to host the group management API.
>> 
>>>>   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
>>> 
>>> Same question as #3.
>> 
>> You are right. Passwords should not go over DBus. Things that change passwords should use PAM directly.
>> 
>>>> 
>>>>   5. LIST_USER_DETAILS
>>>>       Privilege-required: USER-MANAGER
>>>>       Args:
>>>>           NULL
>>>>       Return:
>>>>           Array of:
>>>>               USER_NAME (String)
>>>>               ROLES (String)
>>> 
>>> Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects 
>>> for this?
>> 
>> Yes.
>> 
>>>> 
>>>> Signals:
>>>>   1. UPDATED_USER_SIGNAL
>>>>       Args:
>>>>           UserName of updated user
>>>>           UpdateType:
>>>>               Role changed / User Deleted / User created / Password
>>> 
>>> Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?
>> 
>> Yes.
>> 
>> --Vernon

RE: OpenBMC community telecon - 11/27 Agenda

[Stewart Smith]

Michael.E.Brown@dell.com writes:
> The main issue is one of security. And I realize here that openbmc has a different security model than our product, but here goes:
>
> The "ipmi/web/etc" users are "attacker controlled", if you consider
> the end-user the adversary and are trying to protect the internal
> functioning of the product. That may sound a bit off, but the main
> thing here is that we don't want to allow the user(/administrator) to
> do something that would break the product or allow an insecure
> situation. In our product we now have all of our internal daemons
> running as non-root and a separate user account for each daemon. For
> example: the "powerd" daemon runs as the "power" user and "power"
> group. That linux user has permissions to the /dev entries it needs to
> function, but does not have access to things like KVM or other
> infrastructure or hardware that it doesn’t need. Since we allow "ssh"
> logins to a (minimalistic) shell (either racadm or a smash compatible
> clp), that represents an attack surface. If the user were able to
> create user called "power" that is a linux user and an ipmi/web user
> and they logged into the box as that 'power' user, it would be have
> the same permissions as our power daemon. We try to lock down the
> default shells for non-privileged users but this would represent a
> possible entry point.

Neat!

I've thought that OpenBMC would be a good candidate for a really
restrictive set of SELinux policy too (or some other security module),
to further mitigate any possible damage that could be done even in the
event of a vulnerability.

Have you looked into anything like that at all?

-- 
Stewart Smith
OPAL Architect, IBM.

RE: OpenBMC community telecon - 11/27 Agenda

[Michael.E.Brown]

We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.

<soapbox mode="on">
I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
</soapbox>

My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.

If you run all the daemons as different users, that tends to sort out design issues.

Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.

--
Michael

-----Original Message-----
From: Stewart Smith [mailto:stewart@linux.vnet.ibm.com] 
Sent: Thursday, December 21, 2017 6:43 PM
To: Brown, Michael E <Michael_E_Brown@Dell.com>; bradleyb@fuzziesquirrel.com
Cc: vernon.mauery@linux.intel.com; openbmc@lists.ozlabs.org; richard.marian.thomaiyar@linux.intel.com
Subject: RE: OpenBMC community telecon - 11/27 Agenda

Michael.E.Brown@dell.com writes:
> The main issue is one of security. And I realize here that openbmc has a different security model than our product, but here goes:
>
> The "ipmi/web/etc" users are "attacker controlled", if you consider 
> the end-user the adversary and are trying to protect the internal 
> functioning of the product. That may sound a bit off, but the main 
> thing here is that we don't want to allow the user(/administrator) to 
> do something that would break the product or allow an insecure 
> situation. In our product we now have all of our internal daemons 
> running as non-root and a separate user account for each daemon. For
> example: the "powerd" daemon runs as the "power" user and "power"
> group. That linux user has permissions to the /dev entries it needs to 
> function, but does not have access to things like KVM or other 
> infrastructure or hardware that it doesn’t need. Since we allow "ssh"
> logins to a (minimalistic) shell (either racadm or a smash compatible 
> clp), that represents an attack surface. If the user were able to 
> create user called "power" that is a linux user and an ipmi/web user 
> and they logged into the box as that 'power' user, it would be have 
> the same permissions as our power daemon. We try to lock down the 
> default shells for non-privileged users but this would represent a 
> possible entry point.

Neat!

I've thought that OpenBMC would be a good candidate for a really restrictive set of SELinux policy too (or some other security module), to further mitigate any possible damage that could be done even in the event of a vulnerability.

Have you looked into anything like that at all?

--
Stewart Smith
OPAL Architect, IBM.

Re: OpenBMC community telecon - 11/27 Agenda

[Vernon Mauery]

On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
>We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
>
><soapbox mode="on">
>I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
></soapbox>
>
>My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
>
>If you run all the daemons as different users, that tends to sort out design issues.
>
>Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
>	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
>	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
>	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
>	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
>	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
>	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.

I fully support your direction with the "run each daemon as its own 
user" policy. Almost nothing should be running as root anymore. I don't 
have any SELinux experience, so it is great to have someone in the 
community that does and is willing to drive that.

Have you considered using user namespaces to avoid username collisions 
with system users and user-chosen names (like if an IPMI user wanted to 
pick 'root' as the name)? I have seen people demonstrate how you can use 
containers to do this, but I have not yet figured out how it all works.

The reason I don't like the NSS mechanism with a single unix user that 
you proposed is that it allows users to attack each other, which can 
lead to privilege escalations as well. If the non-system users are 
namespaced, they can be called whatever they want and have whatever ID 
they want, but as far as the kernel goes, they are separate users and 
all non-root.

--Vernon

>--
>Michael
>
>-----Original Message-----
>From: Stewart Smith [mailto:stewart@linux.vnet.ibm.com]
>Sent: Thursday, December 21, 2017 6:43 PM
>To: Brown, Michael E <Michael_E_Brown@Dell.com>; bradleyb@fuzziesquirrel.com
>Cc: vernon.mauery@linux.intel.com; openbmc@lists.ozlabs.org; richard.marian.thomaiyar@linux.intel.com
>Subject: RE: OpenBMC community telecon - 11/27 Agenda
>
>Michael.E.Brown@dell.com writes:
>> The main issue is one of security. And I realize here that openbmc has a different security model than our product, but here goes:
>>
>> The "ipmi/web/etc" users are "attacker controlled", if you consider
>> the end-user the adversary and are trying to protect the internal
>> functioning of the product. That may sound a bit off, but the main
>> thing here is that we don't want to allow the user(/administrator) to
>> do something that would break the product or allow an insecure
>> situation. In our product we now have all of our internal daemons
>> running as non-root and a separate user account for each daemon. For
>> example: the "powerd" daemon runs as the "power" user and "power"
>> group. That linux user has permissions to the /dev entries it needs to
>> function, but does not have access to things like KVM or other
>> infrastructure or hardware that it doesn’t need. Since we allow "ssh"
>> logins to a (minimalistic) shell (either racadm or a smash compatible
>> clp), that represents an attack surface. If the user were able to
>> create user called "power" that is a linux user and an ipmi/web user
>> and they logged into the box as that 'power' user, it would be have
>> the same permissions as our power daemon. We try to lock down the
>> default shells for non-privileged users but this would represent a
>> possible entry point.
>
>Neat!
>
>I've thought that OpenBMC would be a good candidate for a really restrictive set of SELinux policy too (or some other security module), to further mitigate any possible damage that could be done even in the event of a vulnerability.
>
>Have you looked into anything like that at all?
>
>--
>Stewart Smith
>OPAL Architect, IBM.
>

Re: OpenBMC community telecon - 11/27 Agenda

[Michael E Brown]

On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
> On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
> > We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
> > 
> > <soapbox mode="on">
> > I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
> > </soapbox>
> > 
> > My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
> > 
> > If you run all the daemons as different users, that tends to sort out design issues.
> > 
> > Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
> > 	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
> > 	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
> > 	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
> > 	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
> > 	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
> > 	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
> 
> I fully support your direction with the "run each daemon as its own user"
> policy. Almost nothing should be running as root anymore. 

Looks like I need to do some builds and look at this, as I'm operating off old
information then.

> I don't have any SELinux experience, so it is great to have someone in the
> community that does and is willing to drive that.

Thanks

> Have you considered using user namespaces to avoid username collisions with
> system users and user-chosen names (like if an IPMI user wanted to pick
> 'root' as the name)? I have seen people demonstrate how you can use
> containers to do this, but I have not yet figured out how it all works.

I've given this a little bit of thought. Yes, you could use some user
namespaces for this, though to be honest I don't really think it buys all that
much. You can limit ptrace with yama and basically protect the users from each
other pretty well that way, all using a single account. But we could add user
namespaces here as well. The hard part would be in figuring out how to do dbus
level security. I think we'll need to have a unified policy around security of
dbus to tie everything together.

> The reason I don't like the NSS mechanism with a single unix user that you
> proposed is that it allows users to attack each other, which can lead to
> privilege escalations as well. If the non-system users are namespaced, they
> can be called whatever they want and have whatever ID they want, but as far
> as the kernel goes, they are separate users and all non-root.

I think the overriding question here is what kind of shell access do we want to
give to users of openbmc, and what permissions do we want to give them in the
shell? If we want as a project to have the default openbmc "ssh" access be to a
bash shell, then we need to do a lot more around security to get this all to
work well. This is also going to be very difficult to make sure we get
everything correct, however, it is do-able.

On Dell's product, we have a custom shell, and users don't have any generic
system access. Users have no write access to any filesystems, so there is no
way for any logged in user to attack another user via a file.  This pretty
effective in our product.

If we want to have openbmc give shell access to users, lets figure out what
that looks like from a security perspective.

NSS/PAM and one "linux" account, lets call it 'bmcuser'. We'll call the
accounts that users use "bmc accounts". (for example, user could create 'user1'
and 'user2' and those would not show up as linux accounts) It would be
relatively straightforward, I believe, to ensure that one bmc account cannot
attack another bmc account even if both are running in the same linux account,
either with or without namespaces.

With or without namespaces:
	- Need a way to unambiguously set security policy so that things like
dbus calls can have appropriate security applied. Likely the best way to do
this is via normal linux groups. Then we need a comprehensive policy for dbus
to apply the group security policy. This way, we can apply policy for shell
users when they do things like busctl, or use cli utilities that make dbus
calls.
	- Need to ensure that all writable filesystems are mounted noexec to
prevent silly shell attacks.

Without namespaces: 
	- use the yama security patches to disable ptrace for non-children. 
	- possibly use seccomp to disable ptrace() 
	- possibly use seccomp to disable kill()

With namespaces:
	- set bmcuser login shell to a special wrapper which spawns new
namespace, sets groups appropriately, and exec's shell.

--
Michael

Re: OpenBMC community telecon - 11/27 Agenda

[Christopher Covington]

[-- Attachment #1: Type: text/plain, Size: 6994 bytes --]

In case there are others out there for whom PAM/NSS (and the implied LDAP?) may not quite fit, I've recently been configuring SSH trusted CA and authorized principals lists, and like it a lot. https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/

________________________________
From: openbmc <openbmc-bounces+cov=fb.com@lists.ozlabs.org> on behalf of Michael E Brown <Michael.E.Brown@dell.com>
Sent: Thursday, January 4, 2018 8:58:05 AM
To: Vernon Mauery
Cc: stewart@linux.vnet.ibm.com; openbmc@lists.ozlabs.org; bradleyb@fuzziesquirrel.com; richard.marian.thomaiyar@linux.intel.com; Michael.E.Brown@dell.com
Subject: Re: OpenBMC community telecon - 11/27 Agenda

On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
> On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
> > We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
> >
> > <soapbox mode="on">
> > I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
> > </soapbox>
> >
> > My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
> >
> > If you run all the daemons as different users, that tends to sort out design issues.
> >
> > Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
> >      - phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
> >      - phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
> >      - phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
> >      - phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
> >      - On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
> >      - SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
>
> I fully support your direction with the "run each daemon as its own user"
> policy. Almost nothing should be running as root anymore.

Looks like I need to do some builds and look at this, as I'm operating off old
information then.

> I don't have any SELinux experience, so it is great to have someone in the
> community that does and is willing to drive that.

Thanks

> Have you considered using user namespaces to avoid username collisions with
> system users and user-chosen names (like if an IPMI user wanted to pick
> 'root' as the name)? I have seen people demonstrate how you can use
> containers to do this, but I have not yet figured out how it all works.

I've given this a little bit of thought. Yes, you could use some user
namespaces for this, though to be honest I don't really think it buys all that
much. You can limit ptrace with yama and basically protect the users from each
other pretty well that way, all using a single account. But we could add user
namespaces here as well. The hard part would be in figuring out how to do dbus
level security. I think we'll need to have a unified policy around security of
dbus to tie everything together.

> The reason I don't like the NSS mechanism with a single unix user that you
> proposed is that it allows users to attack each other, which can lead to
> privilege escalations as well. If the non-system users are namespaced, they
> can be called whatever they want and have whatever ID they want, but as far
> as the kernel goes, they are separate users and all non-root.

I think the overriding question here is what kind of shell access do we want to
give to users of openbmc, and what permissions do we want to give them in the
shell? If we want as a project to have the default openbmc "ssh" access be to a
bash shell, then we need to do a lot more around security to get this all to
work well. This is also going to be very difficult to make sure we get
everything correct, however, it is do-able.

On Dell's product, we have a custom shell, and users don't have any generic
system access. Users have no write access to any filesystems, so there is no
way for any logged in user to attack another user via a file.  This pretty
effective in our product.

If we want to have openbmc give shell access to users, lets figure out what
that looks like from a security perspective.

NSS/PAM and one "linux" account, lets call it 'bmcuser'. We'll call the
accounts that users use "bmc accounts". (for example, user could create 'user1'
and 'user2' and those would not show up as linux accounts) It would be
relatively straightforward, I believe, to ensure that one bmc account cannot
attack another bmc account even if both are running in the same linux account,
either with or without namespaces.

With or without namespaces:
        - Need a way to unambiguously set security policy so that things like
dbus calls can have appropriate security applied. Likely the best way to do
this is via normal linux groups. Then we need a comprehensive policy for dbus
to apply the group security policy. This way, we can apply policy for shell
users when they do things like busctl, or use cli utilities that make dbus
calls.
        - Need to ensure that all writable filesystems are mounted noexec to
prevent silly shell attacks.

Without namespaces:
        - use the yama security patches to disable ptrace for non-children.
        - possibly use seccomp to disable ptrace()
        - possibly use seccomp to disable kill()

With namespaces:
        - set bmcuser login shell to a special wrapper which spawns new
namespace, sets groups appropriately, and exec's shell.

--
Michael


[-- Attachment #2: Type: text/html, Size: 8945 bytes --]

Re: OpenBMC community telecon - 11/27 Agenda

[Michael E Brown]

On Thu, Jan 04, 2018 at 10:58:04AM -0600, Michael E Brown wrote:
> On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
> > On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
> > > We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
> > > 
> > > <soapbox mode="on">
> > > I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
> > > </soapbox>
> > > 
> > > My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
> > > 
> > > If you run all the daemons as different users, that tends to sort out design issues.
> > > 
> > > Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
> > > 	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
> > > 	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
> > > 	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
> > > 	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
> > > 	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
> > > 	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
> > 
> > I fully support your direction with the "run each daemon as its own user"
> > policy. Almost nothing should be running as root anymore. 
> 
> Looks like I need to do some builds and look at this, as I'm operating off old
> information then.

We updated our openbmc tree to the latest upstream as of the beginning of Dec, so we are a few weeks out. But I am seeing a discrepancy here when I went and looked that I'd like to figure out. I logged into a build of openbmc running on our development hardware and literally everything in the system is running as root with the exception of DBUS and two systemd daemons. Are we missing something here?

After seeing the processes all running as root in our build, I examined the service files in the openbmc git repository.  I'm looking at the openbmc git repo, and picked some things at random:

https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/obmc-fru-fault-monitor.service

https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/xyz.openbmc_project.LED.GroupManager.service

https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-monitor%40.service

https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-presence%40.service

I examined others as well. None of these files have a User= or Group= directive.

You can do a "ps -ef | grep phosphor" and see that the second column shows that all of the phosphor processes are running as root, including the web server and processes that listen on the network. This is all very concerning and at odds with anything resembling good security practice.

What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.

--
Michael

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

> On Jan 6, 2018, at 11:57 AM, Michael E Brown <Michael.E.Brown@dell.com> wrote:
> 
> On Thu, Jan 04, 2018 at 10:58:04AM -0600, Michael E Brown wrote:
>> On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
>>> On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
>>>> We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
>>>> 
>>>> <soapbox mode="on">
>>>> I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
>>>> </soapbox>
>>>> 
>>>> My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
>>>> 
>>>> If you run all the daemons as different users, that tends to sort out design issues.
>>>> 
>>>> Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
>>>> 	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
>>>> 	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
>>>> 	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
>>>> 	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
>>>> 	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
>>>> 	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
>>> 
>>> I fully support your direction with the "run each daemon as its own user"
>>> policy. Almost nothing should be running as root anymore. 
>> 
>> Looks like I need to do some builds and look at this, as I'm operating off old
>> information then.
> 
> We updated our openbmc tree to the latest upstream as of the beginning of Dec, so we are a few weeks out. But I am seeing a discrepancy here when I went and looked that I'd like to figure out. I logged into a build of openbmc running on our development hardware and literally everything in the system is running as root with the exception of DBUS and two systemd daemons. Are we missing something here?
> 
> After seeing the processes all running as root in our build, I examined the service files in the openbmc git repository. I'm looking at the openbmc git repo, and picked some things at random:
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/obmc-fru-fault-monitor.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/xyz.openbmc_project.LED.GroupManager.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-monitor%40.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-presence%40.service
> 
> I examined others as well. None of these files have a User= or Group= directive.
> 
> You can do a "ps -ef | grep phosphor" and see that the second column shows that all of the phosphor processes are running as root, including the web server and processes that listen on the network. This is all very concerning and at odds with anything resembling good security practice.
> 
> What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.

You aren’t missing anything.  I think what Vernon meant was, in 2018, software
stacks should not be running everything as root.

Everyone wants this, it just hasn’t been enough of a priority for anyone
such that it hasn’t been fixed yet.  It should have been done this way in
the first place.  But it wasn’t, so here we are.

FWIW I did add some code to obmc-phosphor-systemd.bbclass quite some time ago
such that configuring a service to run as non-root is trivial, as far as systemd
unit and user/group database configuration goes.  It isn’t used anywhere because
the other side of it is writing the udev rules (or however you want to make sure
the devices have the correct permissions).  I also put code in
obmc-phosphor-dbus-service.bbclass for easy configuration of restrictive dbus
scope permissions that might help with that aspect as well.


> 
> --
> Michael

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

> On Jan 6, 2018, at 11:57 AM, Michael E Brown <Michael.E.Brown@dell.com> wrote:
> 
> On Thu, Jan 04, 2018 at 10:58:04AM -0600, Michael E Brown wrote:
>> On Thu, Dec 28, 2017 at 03:37:14PM -0800, Vernon Mauery wrote:
>>> On 22-Dec-2017 05:21 PM, Michael.E.Brown@dell.com wrote:
>>>> We have spent almost two years now writing a comprehensive SELinux policy for our product. Our current shipping product has SELinux enabled and in "permissive" mode for field testing. Our next major release will have SELinux in enforcing mode, barring major issues in testing. We just had outside security auditors take a look at the implementation and I must say that I'm very pleased with the outcome.
>>>> 
>>>> <soapbox mode="on">
>>>> I strongly encourage every embedded project to have a comprehensive SELinux policy, to enable that policy at the earliest possible opportunity during development, and to have a robust solution and development methodology to run all daemons as NON-root. My personal experience is that it is extraordinarily difficult to retrofit SELinux policy onto a legacy codebase and that it is very difficult to convert an existing codebase running as root to full non-root. What tends to happen is that unrelated things get stuffed into the "wrong" places and things break in both spectacular and subtle ways, sometimes at the same time, when you try to do the conversion from root -> noroot and DAC -> MAC. The earlier you make this transition, the easier things are, long term.
>>>> </soapbox>
>>>> 
>>>> My biggest problem right now with openbmc is that everything runs as root and there is no selinux. Huge step backwards for me. :)  This is one major thing that I would like to help drive in OpenBMC.
>>>> 
>>>> If you run all the daemons as different users, that tends to sort out design issues.
>>>> 
>>>> Now, on to the good stuff I can say: The openbmc design lends itself *really* well to both non-root and SELinux. Having DBUS as the common interface should let us do something like:
>>>> 	- phosphor-hwmon runs as "hwmon" user and group. (systemd service file settings User=, Group=)
>>>> 	- phosphor-hwmon installs systemd-tmpfiles to change file ownership of the sysfs files needed to run hwmon daemons as hwmon user
>>>> 	- phosphor-hwmon installs DBUS policy files to allow itself to own the dbus endpoints
>>>> 	- phosphor-hwmon dbus policy files specify a group that can be used to call the dbus endpoints (eg. "hwmon_read")
>>>> 	- On the other side of this, the thermal daemons run with supplementary groups "hwmon_read" (systemd SupplementaryGroups=)
>>>> 	- SELinux policy written for phosphor-hwmon that allows it to *only* read hwmon sysfs files, and talk to DBUS.
>>> 
>>> I fully support your direction with the "run each daemon as its own user"
>>> policy. Almost nothing should be running as root anymore. 
>> 
>> Looks like I need to do some builds and look at this, as I'm operating off old
>> information then.
> 
> We updated our openbmc tree to the latest upstream as of the beginning of Dec, so we are a few weeks out. But I am seeing a discrepancy here when I went and looked that I'd like to figure out. I logged into a build of openbmc running on our development hardware and literally everything in the system is running as root with the exception of DBUS and two systemd daemons. Are we missing something here?
> 
> After seeing the processes all running as root in our build, I examined the service files in the openbmc git repository. I'm looking at the openbmc git repo, and picked some things at random:
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/obmc-fru-fault-monitor.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/leds/phosphor-led-manager/xyz.openbmc_project.LED.GroupManager.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-monitor%40.service
> 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-gpio-presence%40.service
> 
> I examined others as well. None of these files have a User= or Group= directive.
> 
> You can do a "ps -ef | grep phosphor" and see that the second column shows that all of the phosphor processes are running as root, including the web server and processes that listen on the network. This is all very concerning and at odds with anything resembling good security practice.
> 
> What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.

You aren’t missing anything.  I think what Vernon meant was, in 2018, software
stacks should not be running everything as root.

Everyone wants this, it just hasn’t been enough of a priority for anyone
such that it hasn’t been fixed yet.  It should have been done this way in
the first place.  But it wasn’t, so here we are.

FWIW I did add some code to obmc-phosphor-systemd.bbclass quite some time ago
such that configuring a service to run as non-root is trivial, as far as systemd
unit and user/group database configuration goes.  It isn’t used anywhere because
the other side of it is writing the udev rules (or however you want to make sure
the devices have the correct permissions).  I also put code in
obmc-phosphor-dbus-service.bbclass for easy configuration of restrictive dbus
scope permissions that might help with that aspect as well.


> 
> --
> Michael

Re: OpenBMC community telecon - 11/27 Agenda

[Michael E Brown]

On Sat, Jan 06, 2018 at 12:33:26PM -0500, Brad Bishop wrote:
> 
> > What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.
> 
> You aren’t missing anything.  I think what Vernon meant was, in 2018, software
> stacks should not be running everything as root.

Oh, ok, looks like I read that in a totally different way! I was starting to
get concerned, thanks for clarifying.

> Everyone wants this, it just hasn’t been enough of a priority for anyone
> such that it hasn’t been fixed yet.  It should have been done this way in
> the first place.  But it wasn’t, so here we are.

So, what is the best way forward? We have a time set aside at the hackathon to
talk about this? What is the most productive way to use that time? I would be
happy to put together some (barebones) slides to go over what we did in our
product to get to where we are at. We could even do live hackathon to try to
convert some daemons. What do you think?

> FWIW I did add some code to obmc-phosphor-systemd.bbclass quite some time ago
> such that configuring a service to run as non-root is trivial, as far as systemd
> unit and user/group database configuration goes.  It isn’t used anywhere because
> the other side of it is writing the udev rules (or however you want to make sure
> the devices have the correct permissions).  I also put code in
> obmc-phosphor-dbus-service.bbclass for easy configuration of restrictive dbus
> scope permissions that might help with that aspect as well.

That sounds like a good start.
--
Michael

Re: OpenBMC community telecon - 11/27 Agenda

[Brad Bishop]

> On Jan 8, 2018, at 11:25 AM, Michael E Brown <Michael.E.Brown@dell.com> wrote:
> 
> On Sat, Jan 06, 2018 at 12:33:26PM -0500, Brad Bishop wrote:
>> 
>>> What am I missing here? You said above, "nothing should be running as root anymore", but I very clearly see literally everything running as root. I have a feeling that I am missing something important.
>> 
>> You aren’t missing anything.  I think what Vernon meant was, in 2018, software
>> stacks should not be running everything as root.
> 
> Oh, ok, looks like I read that in a totally different way! I was starting to
> get concerned, thanks for clarifying.
> 
>> Everyone wants this, it just hasn’t been enough of a priority for anyone
>> such that it hasn’t been fixed yet.  It should have been done this way in
>> the first place.  But it wasn’t, so here we are.
> 
> So, what is the best way forward? We have a time set aside at the hackathon to
> talk about this? What is the most productive way to use that time? I would be
> happy to put together some (barebones) slides to go over what we did in our
> product to get to where we are at. We could even do live hackathon to try to
> convert some daemons. What do you think?

Thanks for leading this discussion at the hackathon.  I’d vote for trying to
convert one, or at least enumerating the steps to do it to make it easy for
the next person that spends some time on it.  I’d suggest starting out with an
application that doesn't have any user interface component, to side-step the
current discussion around linux/non-linux users.  Hwmon seems like a good
candidate.

> 
>> FWIW I did add some code to obmc-phosphor-systemd.bbclass quite some time ago
>> such that configuring a service to run as non-root is trivial, as far as systemd
>> unit and user/group database configuration goes.  It isn’t used anywhere because
>> the other side of it is writing the udev rules (or however you want to make sure
>> the devices have the correct permissions).  I also put code in
>> obmc-phosphor-dbus-service.bbclass for easy configuration of restrictive dbus
>> scope permissions that might help with that aspect as well.
> 
> That sounds like a good start.
> --
> Michael