User-manager default group roles

User-manager default group roles

[Joseph Reynolds]

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.

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?

- 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

Re: User-manager default group roles

[Thomaiyar, Richard Marian]

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

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>

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

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

Re: User-manager default group roles

[Joseph Reynolds]

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.

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.

I understand the full set of work for this includes:
1. Create the "ssh" Linux group to represent the "ssh" group role.
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.

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

Re: User-manager default group roles

[Thomaiyar, Richard Marian]

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.

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

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

Re: User-manager default group roles

[Joseph Reynolds]

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

>
> 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", {}}
     };

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

Re: User-manager default group roles

[Thomaiyar, Richard Marian]

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


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

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