Disable Local Users Proposal

Ratan Gupta ratagupt at linux.vnet.ibm.com
Mon Aug 13 18:21:45 AEST 2018


Hi Matt,

Please find my comments inline

Ratan



On Saturday 11 August 2018 02:57 AM, Matt Spinler wrote:
> Hi,
>
> We have a requirement to disable all local accounts on the BMC,
> including root, so the only logins allowed would be via LDAP 
> authenticated
> accounts.
>
> It was recommended that I do this by removing the pam_unix module from
> /etc/pam.d/common-auth and/or common-account(I think?), and also remove
> ~/.ssh/authorized_keys if present.
By removing the authorized_keys means if somebody have uploaded their 
keys to enable the password
less login.
so by doing so we are removing that possibility.Is it correct or is 
there some other intent?
>
> I see that the upcoming user manager code in
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-user-manager/+/10112/ 
>
> doesn't deal with system accounts, which we also need to disable, so 
> my proposal
> is to add an 'AllLocalAccountsDisabled' property to 
> xyz.openbmc_projects.Users.Manager
> to do the disable/reenable by modifying the PAM files.
>
> I'm thinking this would be independent of the UserEnabled property in the
> Users.Attributes interface, though I could also do the UserEnabled(false)
> on all existing users and disallow anyone from setting to true.
I agree with you on introducing other property 
"AllLocalAccountsDisabled" but we should
be consistent that each individual user status should also show its 
status as disabled.
it should not be that if admin does enumerate on the users namespace 
then manager
interface shows that AllLocalAccountsDisabled is true but each 
individual user property show the
userEnabled as true.
>
> There seems to be a bug in the REST server right now that still allows 
> REST
> access with a root login with root disabled, so that would need to be 
> fixed,
> but eventually one could still use LDAP authenticated users to make 
> REST calls.
>
> This would not affect IPMI.
>
> Comments/ideas welcome
>
> Matt
>



More information about the openbmc mailing list