<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 11/18/2020 10:23 PM, Joseph Reynolds
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c0ad5f1b-43de-2db9-8b71-29dd14a067ec@linux.ibm.com">On
11/18/20 1:11 AM, Thomaiyar, Richard Marian wrote:
<br>
<blockquote type="cite">
<br>
On 11/18/2020 12:47 AM, Joseph Reynolds wrote:
<br>
<blockquote type="cite">On 11/17/20 11:21 AM, Thomaiyar, Richard
Marian wrote:
<br>
<blockquote type="cite">Hi Joseph, For SSH to work fine, user
must be part of priv-admin...
<br>
This Message Is From an External Sender
<br>
This message came from outside your organization.
<br>
<br>
Hi Joseph,
<br>
<br>
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.
<br>
usermod --shell /bin/sh -G priv-admin ${USER}
<br>
<br>
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
<a class="moz-txt-link-rfc2396E" href="https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default"><https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default></a><br>
</blockquote>
<br>
Richard,
<br>
<br>
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.
<br>
</blockquote>
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.
<br>
<blockquote type="cite">
<br>
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.
<br>
<br>
</blockquote>
Yes, i see your use case and user must be able to ssh
irrespective of privilege role he is in.
<br>
<blockquote type="cite">I understand the full set of work for
this includes:
<br>
1. Create the "ssh" Linux group to represent the "ssh" group
role.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
Thanks for explaining! Yes, using /bin/nologin works just as
well...and does not need a new Linux group.
<br>
<br>
<blockquote type="cite">
<br>
<blockquote type="cite">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.
<br>
3. Change phosphor-user-manager [6] to re-swizzle the login
shell path when a user is added or removed from the "ssh"
group.
<br>
4. Implement BMCWeb REST APIs [7], if desired.
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
</blockquote>
<br>
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?)
<br>
<br>
- Joseph
<br>
<br>
</blockquote>
<p>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<br>
</p>
<p><u><b>To remove SSH group:</b></u><br>
</p>
<p>If SSH needs to be disabled for all newly created users (during
runtime), then please remove "ssh" from
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp#L200">https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp#L200</a>
(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).</p>
<p>Note: We can make this groups & privileges configurable using
bb configuration to have easy override.<br>
</p>
<p><u><b>To add ssh to dummyuser (build time):</b></u></p>
<p>In local.conf.sample please add the following under
EXTRA_USERS_PARAMS (Note: dummyuser can be created using
USERADD_PARAM).<br>
</p>
<p> usermod --shell /bin/sh dummyuser; \</p>
<p> 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.</p>
<p>Let me know, if this works, we can make this as configurable<br>
</p>
<blockquote type="cite"
cite="mid:c0ad5f1b-43de-2db9-8b71-29dd14a067ec@linux.ibm.com">
<blockquote type="cite">
<br>
Regards,
<br>
<br>
Richard
<br>
<br>
<blockquote type="cite">
<br>
- Joseph
<br>
<br>
P.S. I intend to repeat this exercise for the ipmi group role.
<br>
<br>
[6]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Attributes.interface.yaml">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Attributes.interface.yaml</a><br>
[7]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp">https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp</a><br>
<br>
<blockquote type="cite">Regards,
<br>
<br>
Richard
<br>
<br>
On 11/17/2020 3:49 AM, Joseph Reynolds wrote:
<br>
<blockquote type="cite">
<br>
What is the right way to assign default
phosphor-user-manager "group roles" to dynamically created
users?
<br>
<br>
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.
<br>
<br>
</blockquote>
usermod --shell /bin/sh -G priv-admin ${USER} is the correct
command for per[3].
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
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:
<br>
- User must be a member of the "priv-admin" group. I intend to
remove this check.
<br>
- User's login shell is used. If /bin/sh then the user gains
access. If /bin/nologin then the SSH session exits.
<br>
<br>
I think that works for me.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">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.
<br>
<br>
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?
<br>
</blockquote>
As of today, we are not separating user groups. All users
created in OpenBMC belongs to the build time configured
groups.
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
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?<br>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:c0ad5f1b-43de-2db9-8b71-29dd14a067ec@linux.ibm.com">To
control the defaults and provide a general mechanism, I propose a
new D-Bus property for [5]:
<br>
- name: DefaultGroups
<br>
type: dict[string, array[string]]
<br>
flags:
<br>
- const
<br>
description: >
<br>
Maps from each privilege in AllPrivileges to the default
groups for
<br>
that privilege role (a subset of AllGroups) in a form
suitable for
<br>
CreateUser.GroupNames.
<br>
<br>
with implementation [4] in:
<br>
/** @brief Maps from privilege to default set of groups */
<br>
std::map<std::string,std::vector<std::string>>
privToGroupsMgr =
<br>
{
<br>
{"priv-admin", {"web", "redfish", "ipmi", "ssh"}},
<br>
{"priv-operator", {"web", "redfish", "ipmi"}},
<br>
{"priv-user", {"web", "redfish", "ipmi"}},
<br>
{"priv-noaccess", {}}
<br>
};
<br>
<br>
</blockquote>
<p>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<br>
</p>
<p>privileges / roles --> Used to provide authorization level for
the OpenBMC application. <br>
</p>
<p>groups --> Used to indicate whether user is allowed to be
authenticated with the specified application. <br>
</p>
<p>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.</p>
<p>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.</p>
<p>Regards,</p>
<p>Richard<br>
</p>
<blockquote type="cite"
cite="mid:c0ad5f1b-43de-2db9-8b71-29dd14a067ec@linux.ibm.com">Then
when BMCWeb creates a new local account [7], it can use the new
DefaultGroups property (indexed by the role) instead of AllGroups.
<br>
<br>
- Joseph
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
- Joseph
<br>
<br>
[1]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/docs/blob/master/architecture/user-management.md">https://github.com/openbmc/docs/blob/master/architecture/user-management.md</a><br>
[2]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/bmcweb/blob/929d4b57f10bc4200e16b71fbcf32521d8cc23c1/redfish-core/lib/account_service.hpp#L1435">https://github.com/openbmc/bmcweb/blob/929d4b57f10bc4200e16b71fbcf32521d8cc23c1/redfish-core/lib/account_service.hpp#L1435</a><br>
[3]: <a class="moz-txt-link-freetext" href="https://github.com/openbmc/openbmc/issues/3643">https://github.com/openbmc/openbmc/issues/3643</a>
<br>
[4]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp">https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.hpp</a><br>
[5]:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Manager.interface.yaml">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Manager.interface.yaml</a><br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>