Re: Re： How can I add a user for openbmc and remove the default root user?

[Joseph Reynolds]

On 12/19/19 3:09 AM, Thomaiyar, Richard Marian wrote:
>
> On 12/19/2019 12:06 PM, Joseph Reynolds wrote:
>> On 12/18/19 6:42 AM, Thomaiyar, Richard Marian wrote:
>>> Hi Gunnar,
>>>
>>> Yes root user can't be deleted (basically uid 0), can't be deleted. 
>>> The method works for other users only, like in case Liu, he wants to 
>>> delete the newly created user.
>>
>> FWIW, I am interested in moving the OpenBMC project away from having 
>> root login access enabled by default, and specifically disabling SSH 
>> access in general, and root access to the BMC's shell.  I also want 
>> to have a secure way to re-enable this when needed.  See 
>> https://github.com/ibm-openbmc/dev/issues/1528 Please let me know if 
>> you have any ideas on this topic.
>>
> Currently you will be. Remove debug-tweaks & allow-root-login from 
> IMAGE_FEATURES, then the build will make sure that root user looses 
> group permissions, and OpenBMC is with no user accounts. Any new user 
> accounts must be created from Host interface through IPMI interface 
> (that's the logic we currently have).
>
> Note:
>
> 1. This will not remove the root user (uid 0, which is needed as you 
> mentioned below), but will not have any password (In order to remove 
> the password in the OpenBMC it needs one line change to remove usermod 
> in phosphor-defaults.inc & the /etc/ipmi_pass file, currently we have 
> a patch in the down-stream for the same, as community still needs root 
> user account, but OpenBMC has been updated to remove root user from 
> Admin & other group privileges, when debug-tweaks / allow-root-logins 
> are not defined.

Nice!  Thank you for referencing that (I missed that review).  It seems 
to me that phosphor-defaults.inc should  set the root user password only 
when IMAGE_FEATURES includes allow-root-login, and otherwise not allow 
login.  My bitbake is weak, but something like this:

# Set the root password to '0penBmc' if IMAGE_FEATURES contains 
allow-root-login,
# otherwise use "!" so root cannot login.
EXTRA_USERS_PARAMS_pn-obmc-phosphor-image = " \
usermod -p \
${@bb.utils.contains("IMAGE_FEATURES", 'allow-root-login', "", "!", d}\
'\$1\$UGMqyqdG\$FZiylVFmRRfl9Z0Ue8G7e/' root; \
"
(except use correct bitbake syntax).


BTW, we ought to update the [password hash algorithm][], currently 
$1$=MD5 to $5$=SHA-256 or $6$=SHA-512.
[password hash algorithm]: https://en.wikipedia.org/wiki/Passwd


>
>>
>> I had understood the original question in this email thread as a 
>> request to "disable root access" so "root cannot login".  (Note that 
>> one consequence of disabling root login is that once you remove root 
>> access, it is hard to get back.  You'll have to use the sudo comand 
>> or su command from another user account, and I don't think sudo is 
>> present on OpenBMC systems.)
>>
>> I understand that deleting the root user is not advisable because the 
>> system will break.  Instead the alternative is to disable access to 
>> the root account, for example, by doing one of:
>> - Change root's login shell to /sbin/nologin
>> - Change the root password to empty or lock the root password
>> - Change Linux-PAM to deny root account access
>> - Expire the root account (chage -E0 root)
>>
>> Any idea which approach works best for OpenBMC?
>
> If you have removed the password, then it can't be used. But if you 
> need to enable it for debug or on special use case, then it requires a 
> method to set a password. We enable setting the root
> password using Set special user password OEM Command 
> (https://github.com/openbmc/intel-ipmi-oem/blob/master/src/oemcommands.cpp#L1130).
>
> Let me know your thoughts, As i see a decision can be made, i think we 
> can write a document (with community feedback), and move to a common 
> solution.

That sounds right to me.  I think various OpenBMC users have these use 
cases:

Use case 1: remove root access by default

We share the use case of removing root access by default which we can do 
by removing 'allow-root-login' from IMAGE_FEATURES.

I would like to see the OpenBMC project should move toward this as the 
default.  That bring me to use case 2...


Use case 2: have a way to re-enable root access

We also need a way to re-enable root access to the BMC's shell. I 
suggest we design a phosphor D-Bus API as the common way to enable and 
disable root login access.

I see divergent use cases for root shell access.  OpenBMC developers 
will continue to need root login (for example, SSH to the BMC using 
default root credentials) on a regular basis.  They will also need that 
access when they are called upon to debug systems currently running a 
workload.

However, users with sensitive data on their host system will want to 
lock out the root user, all SSH access, and especially root SSH access 
because of the additional capabilities root has compared with regular 
Administrator users and because of the difficulty in monitoring and 
auditing shell commands.  Specifically, I think root login access and 
SSH access must both be addressed.  In my opinion, if we give any users 
SSH access to the BMC shell, it is too easy for them to escalate that 
privilege to root, so we should have a way to lock out SSH access.

The solution you presented is an IPMI OEM command. Another idea is a 
Phosphor REST or Redfish API to control these items (root login and SSH 
server capability), and limit that to the BMC Administrator role.  Those 
APIs would use the D-Bus API as the underlying implementation.

I think OpenBMC needs an easy way to re-enable root access before we can 
remove root access.


Use case 3: create an admin user by default

A related topic is the use cases for the "genesis experience", that is, 
the first time a BMC admin uses their newly-installed BMC.  The options 
include:
A. The BMC has no default users.  When needed, they are created via 
unauthenticated host access.
B. The BMC has no default users.  An Administrator account is created by 
the initial user to access the system.  This would make OpenBMC behave 
like other operating systems (such as Ubuntu) and devices.
C. The BMC has a user with username=admin and role=Administrator and a 
default password.  This is close to what OpenBMC has now and what I 
would propose for the project default.  (Naturally, we would add 
'no-admin-user' to IMAGE_FEATURES for use cases that do not want this user.)

The options above all assume the current genesis & provisioning 
experience.  It would be possible to provision the BMC with its firmware 
image, custom user access credentials, an IP address, etc., before 
powering on the BMC for the first time.  I would like to explore the 
possibilities in that space, but the remainder of this note assumes the 
traditional genesis experience described in the options above.

In any case, the admin user will have a way to gain root login access 
for themselves and to lock out root access by non-admin users.

I think OpenBMC needs to document how to access and provision the BMC, 
including details such as how to login as root and how to lock out root 
access.

___

As usual, I've written too much.  I would be happy to hear your ideas, 
review your solution, and help where I can.

- Joseph


TL;DR: More ramblings for the use cases above: Have a way for a BMC 
Administrator to gain root access to the BMC shell.

What is the use case to allow a non-root user to use the BMC shell (via 
SSH or other access)?  What will that let them do?  I think you need to 
have sudo access for commands like journalctl and systemctl, or to 
invoke D-Bus APIs.  I mean I think what you can do with the BMC's shell 
is extremely limited without sudo access.  Are we thinking we should set 
up sudo?

If we have sudo access (so I can, for example: `ssh admin1@${bmc_ip} 
sudo`) then why would I need to login as root.  Would root login be 
needed?  I think we can do without root logins, but we would need to get 
sudo working...and havde a way to control when sudo is enabled. (In 
other words, I don't have good idea how to handle this.)

Note: Per the [phosphor user management group roles][], should the 
[access via SSH][] be changed to the "ssh" group?  It is currently 
restricted to the priv-admin group.

[phosphor user management group roles]: 
https://github.com/openbmc/docs/blob/master/architecture/user_management.md#supported-group-roles
[Access via SSH]: 
https://github.com/openbmc/openbmc/blob/adb78181f2183a3b0aa016cfd5d754710b828f30/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default


>
>>
>> - Joseph
>>
>>>
>>> Regards,
>>>
>>> Richard
>>>
>>>
>>> On 12/18/2019 2:38 AM, Gunnar Mills wrote:
>>>>
>>>> On 12/16/2019 7:44 AM, Thomaiyar, Richard Marian wrote:
>>>>>
>>>>> Delete interface is exposed as part of the user object itself. 
>>>>> Sample busctl command to do the delete of an user under 
>>>>> phosphor-user-manager
>>>>>
>>>>> busctl call xyz.openbmc_project.User.Manager 
>>>>> /xyz/openbmc_project/user/<username> 
>>>>> xyz.openbmc_project.Object.Delete Delete
>>>>>
>>>>>
>>>>
>>>> I am missing something here.. This does not work for me. I didn't 
>>>> think we allowed removing the root user, which is why it is 
>>>> disabled on the WebUI? If we do allow deleting the root user, 
>>>> should this be allowed from the WebUI?
>>>>
>>>> When sshed as root:
>>>> busctl call xyz.openbmc_project.User.Manager 
>>>> /xyz/openbmc_project/user/root xyz.openbmc_project.Object.Delete 
>>>> Delete
>>>> Call failed: The operation failed internally.
>>>>
>>>> In the journal I see
>>>> Dec 17 20:57:56 w37 phosphor-user-manager[220]: userdel: user root 
>>>> is currently used by process 1
>>>> Dec 17 20:57:56 w37 phosphor-user-manager[220]: The operation 
>>>> failed internally.
>>>> Dec 17 20:57:56 w37 phosphor-user-manager[220]: User delete failed
>>>> Dec 17 20:57:56 w37 phosphor-user-manager[220]: The operation 
>>>> failed internally.
>>>>
>>>>
>>>> When sshed as an "Administrator" role account,  with the same call:
>>>> Call failed: Access denied
>>>>
>>>> NOTE: As an "Administrator" role I can't delete a user using 
>>>> "busctl call" only from the Redfish/WebUI, am I able to.
>>>>
>>>> Thanks!
>>>> Gunnar
>> Regards,
> Richard