User-manager default group roles

Thomaiyar, Richard Marian richard.marian.thomaiyar at linux.intel.com
Thu Nov 19 22:49:53 AEDT 2020 

On 11/18/2020 10:23 PM, Joseph Reynolds wrote:
> On 11/18/20 1:11 AM, Thomaiyar, Richard Marian wrote:
>>
>> On 11/18/2020 12:47 AM, Joseph Reynolds wrote:
>>> On 11/17/20 11:21 AM, Thomaiyar, Richard Marian wrote:
>>>> Hi Joseph, For SSH to work fine, user must be part of priv-admin...
>>>> This Message Is From an External Sender
>>>> This message came from outside your organization.
>>>>
>>>> Hi Joseph,
>>>>
>>>> For SSH to work fine, user must be part of priv-admin and must have 
>>>> command/shell as /bin/sh under /etc/passwd file instead of 
>>>> /bin/nologin. Note: There is no direct group called ssh under 
>>>> /etc/group, instead it is just emulated one from 
>>>> phosphor-user-manager to add corresponding shell binary to the user.
>>>> usermod --shell /bin/sh -G priv-admin ${USER}
>>>>
>>>> If requirement is SSH to be allowed based on group and allowed for 
>>>> all user privileges, then user shell can be updated using usermod 
>>>> --shell /bin/sh itself, but need to remove EXTRA_ARGS from the 
>>>> dropbear.default 
>>>> <https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default>
>>>
>>> Richard,
>>>
>>> Thanks for the info.  I do intend to separate the "ssh" group role 
>>> from the "priv-admin" privilege role.  My use case for the admin to 
>>> NOT have ssh privilege, but the service user account does have ssh 
>>> privilege.  I think this is cleaner and applicable to multiple use 
>>> cases.
>> In this case, need to remove the -G priv-admin from dropbear.defaults 
>> (but all users who have sh command/shell, will be able to login) and 
>> ssh doesn't provide any authorization for commands based on privileges.
>>>
>>> For the OpenBMC project defaults, I propose that when a new user is 
>>> dynamically created with the "priv-admin" role, they also get the 
>>> "ssh" group role.  After the user account is created, I do not 
>>> intend for "priv-admin" and "ssh"  be be tied together, meaning you 
>>> can change one and not the other, and you will get the results you 
>>> expect.
>>>
>> Yes, i see your use case and user must be able to ssh irrespective of 
>> privilege role he is in.
>>> I understand the full set of work for this includes:
>>> 1. Create the "ssh" Linux group to represent the "ssh" group role.
>>
>> Not needed (unless we really require to support usermod command - 
>> "usermod -G "ssh" ${USER}). Won't usermod --shell /bin/sh ${USER} 
>> won't be enough for covering the same. Assuming this is not the way 
>> we are going to ask end-user to create a user.
>
> Thanks for explaining!  Yes, using /bin/nologin works just as 
> well...and does not need a new Linux group.
>
>>
>>> 2. Change the dropbear.defaults to "-G ssh" (was "-G priv-admin"). 
>>> There may be forward compatibility concerns: for example, when this 
>>> changes, everyone in the priv-admin group should be added to the 
>>> "ssh" group.
>>> 3. Change phosphor-user-manager [6] to re-swizzle the login shell 
>>> path when a user is added or removed from the "ssh" group.
>>> 4. Implement BMCWeb REST APIs [7], if desired.
>>
>> We don't require any change in bmweb rest API's for this, as these 
>> are build time configurable (i.e. for ssh priv-admin). 
>> phosphor-user-manager already provided D-Bus property to support 
>> different account groups, i.e. for AccountTypes (Redfish,Ipmi 
>> etc.)(for the schema update you are working with redfish forum). Once 
>> the schema is defined, we just need to update the bmcweb to update 
>> the property accordingly.
>>
>> Let me know if you have any other reason / usecase, which will not 
>> work with this approach. If needed, we can even discuss this in 
>> security WG.
>
> My only other customized use case is to disable SSH access for all 
> roles, including the builtin root/admin user.  To be clear, the SSH 
> service will be present on my BMC, but only my special pre-created 
> "service" account will be allowed to access a BMC command shell via 
> SSH, and the BMC customer/admin has no way to cange who is authorized 
> to use SSH.  <-- I think I get this for free because there are not 
> REST APIs for the admin to control who has SSH access.  (Does SSH 
> authentication use LDAP?)
>
> - Joseph
>
Roles & groups are not directly related, In OpenBMC it is kept 
separately, please refer below for the corrections. Regarding LDAP SSH 
authentication, our current stack won't be able to, as we need to add 
support to create home dir (pam_mkhomedir) for LDAP (which is not 
available today). Apart from making the dropbear.default change (to 
remove priv-admin), please do the following

_*To remove SSH group:*_

If SSH needs to be disabled for all newly created users (during 
runtime), then please remove "ssh" from 
https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp#L200 
(With removal of ssh from here, both IPMI & Redfish will automatically 
detect the same, and further new user creation will happen without SSH 
group support).

Note: We can make this groups & privileges configurable using bb 
configuration to have easy override.

_*To add ssh to dummyuser  (build time):*_

In local.conf.sample please add the following under EXTRA_USERS_PARAMS 
(Note: dummyuser can be created using USERADD_PARAM).

   usermod --shell /bin/sh dummyuser; \

  with the above changes, only root will be able to use ssh and users 
created using IPMI / Redfish won't be able to login to SSH.

Let me know, if this works, we can make this as configurable

>>
>> Regards,
>>
>> Richard
>>
>>>
>>> - Joseph
>>>
>>> P.S. I intend to repeat this exercise for the ipmi group role.
>>>
>>> [6]: 
>>> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Attributes.interface.yaml
>>> [7]: 
>>> https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp
>>>
>>>> Regards,
>>>>
>>>> Richard
>>>>
>>>> On 11/17/2020 3:49 AM, Joseph Reynolds wrote:
>>>>>
>>>>> What is the right way to assign default phosphor-user-manager 
>>>>> "group roles" to dynamically created users?
>>>>>
>>>>> Background: Currently, when a new local user is created via 
>>>>> Redfish API POST /redfish/v1/AccountService/Accounts you have to 
>>>>> specify a Redfish RoleId.  BMCWeb maps the RoleId to a phosphor 
>>>>> user manager "Privilege Role" [1] and assigns ALL of the "group 
>>>>> roles" to the new user [2].  Per [3] this is not intended, and I 
>>>>> need to fix this for my use case.
>>>>>
>>>> usermod --shell /bin/sh -G priv-admin ${USER} is the correct 
>>>> command for per[3].
>
> Got it.  Thanks for explaining.  I understand: membership in the 
> phosphor group-role "ssh" correlates exactly with the user account's 
> login shell being "/bin/sh" (as opposed to "/bin/nologin").  In this 
> way, any user who successfully authenticates to SSH then faces two 
> additional blocks:
>  - User must be a member of the "priv-admin" group.  I intend to 
> remove this check.
>  - User's login shell is used.  If /bin/sh then the user gains 
> access.  If /bin/nologin then the SSH session exits.
>
> I think that works for me.
>
>>>>> IMHO, the correct approach is for the project to define a mapping 
>>>>> from "role" to "privilege role" that can be used when dynamically 
>>>>> creating a new user.  For example, the admin role maps to "ssh 
>>>>> ipmi redfish web" whereas the readonly role maps to "ipmi redfish 
>>>>> web" (omits "ssh"). Then images can customize this as needed.
>>>>>
>>>>> But where should this mapping be applied?  Does it belong in 
>>>>> BMCWeb or in phosphor-user-manager [4]?  Should we have another 
>>>>> D-Bus property [5] to give this mapping?
>>>> As of today, we are not separating user groups. All users created 
>>>> in OpenBMC belongs to the build time configured groups.
>
> Should SSH access only be given to "admin" users?  More generally, 
> what is the intended design to provide the default group roles? Should 
> all dynamically created local user accounts be given "ssh" access?  Or 
> should ssh access only be given to "admin" users?

> To control the defaults and provide a general mechanism, I propose a 
> new D-Bus property for [5]:
>     - name: DefaultGroups
>       type: dict[string, array[string]]
>       flags:
>           - const
>       description: >
>           Maps from each privilege in AllPrivileges to the default 
> groups for
>           that privilege role (a subset of AllGroups) in a form 
> suitable for
>           CreateUser.GroupNames.
>
> with implementation [4] in:
>     /** @brief Maps from privilege to default set of groups */
>     std::map<std::string,std::vector<std::string>> privToGroupsMgr =
>     {
>         {"priv-admin", {"web", "redfish", "ipmi", "ssh"}},
>         {"priv-operator", {"web", "redfish", "ipmi"}},
>         {"priv-user", {"web", "redfish", "ipmi"}},
>         {"priv-noaccess", {}}
>     };
>
Not really, privileges & groups are designed to exist separately. i.e. 
All users created in OpenBMC belong to {"web", "redfish", "ipmi", "ssh"} 
groups, irrespective of their privilege levels

privileges / roles --> Used to provide authorization level for the 
OpenBMC application.

groups --> Used to indicate whether user is allowed to be authenticated 
with the specified application.

Both IPMI & Redfish today allows to configure the privileges/roles for a 
user, but doesn't allow to configure the groups (hence we had a build 
time configured group roles - fixed). With the new AccountTypes property 
discussed, groups can be configured through Redfish and for IPMI we can 
rely on OpenBMC OEM IPMI commands.

i.e. User can belong to group {"web", "redfish", "ipmi", "ssh"} and with 
"priv-user". In this case, web/redfish /ipmi application must allow only 
user privilege related commands to be executed (As authorization based 
control is not available for SSH, for security reason, we limited ssh 
support for priv-admin user only). i.e. Through Redfish / ipmi, if the 
user privilege is increased to "priv-admin" (Administrative) privilege, 
then user can login to ssh too, and if it is changed to "priv-noaccess", 
then it means user is disabled for authorization, and not allowed to do 
any access.

Regards,

Richard

> Then when BMCWeb creates a new local account [7], it can use the new 
> DefaultGroups property (indexed by the role) instead of AllGroups.
>
> - Joseph
>
>>>>>
>>>>> - Joseph
>>>>>
>>>>> [1]: 
>>>>> https://github.com/openbmc/docs/blob/master/architecture/user-management.md
>>>>> [2]: 
>>>>> https://github.com/openbmc/bmcweb/blob/929d4b57f10bc4200e16b71fbcf32521d8cc23c1/redfish-core/lib/account_service.hpp#L1435
>>>>> [3]: https://github.com/openbmc/openbmc/issues/3643
>>>>> [4]: 
>>>>> https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp
>>>>> [5]: 
>>>>> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Manager.interface.yaml
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201119/dd93c594/attachment-0001.htm>

More information about the openbmc mailing list