Disable Local Users Proposal

[Thomaiyar, Richard Marian]

On 8/15/2018 12:40 AM, Matt Spinler wrote:
> Hi Richard,
>
>
> On 2018-08-14 12:48, Thomaiyar, Richard Marian wrote:
>> Hi Matt,
>>
>> I am not sure, whether you want to permanently disable local accounts
>> or only make it in a configurable way ?
>
> We need to let this be done on premise, and not have it baked into an 
> image.
>
>>
>> In order to disable the root user login, have you tried password
>> expiry logic (D-bus interface API provides option to disable the user,
>> which relies on this), which can be set in the /etc/shadow file during
>> compilation itself. Won't this fix your problem instead of removing
>> the pam modules ?
>
> See below
>
>
>  In case if your requirement is to disable it
>> permanently to avoid user creation etc, then user D-Bus interfaces
>> should not be implemented(i.e it should never be exposed). (Also what
>> about serial port login ? by default it will land up  in shell or
>> will be disabled for local accounts here too ?).
>
> We want to disable serial port login too, which this method does, and 
> I assume
> expiring the account does as well.
>
>>
>> Related to the D-Bus interfaces to disable the local accounts (under
>> review), i am not sure, how it is going to be different than disabling
>> each user ?
>
> Just that you weren't creating an object for the root account, or any 
> other
> system accounts, which we also need to disable.  Can you see a design in
> which your code would also create objects for those too, and not allow
> new users to be created if we were in this disabled mode?
I will be pushing next patch, which will be listing root accounts too. 
But as i said, if it has to be disabled by default, then it can be done 
in /etc/shadow
In this scenario --> root / or any user accounts in /etc/passwd file 
will be listed, and accordingly will be marked as disabled (if it is so 
in /etc/shadow).
>
>
>> Because even this property can be set to TRUE and then
>> users can be created / configured right ?
>
> I believe this case involves LDAP users with either write or read-only
> access, and if one with write access wants to enable local users again,
> that is OK as far as we are concerned.  But otherwise, they don't want
> to have to deal with changing BMC passwords every X number of days
> which they'd have to do with local accounts and their IT policies.
>
if disabled in /etc/shadow, then no local user accounts can be used to 
login.
The only way new user can be created is, if LDAP login is allowed to 
have administrative privilege to manage the user accounts or Host to 
IPMI communication to create accounts (I believe that this is the 
configuration
which you want to support right? then i don't find a reason why we need 
a global disable property. Because that property has to be configured in 
both the cases right?).

Regards,
Richard
>
>
>>
>> Regards,
>> Richard
>>
>> On 8/14/2018 8:56 PM, Matt Spinler wrote:
>>> On 2018-08-13 03:21, Ratan Gupta wrote:
>>>> 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?
>>>
>>> It would disable them when the property is set, but then I guess other
>>> users could add them again.  Not sure what else I could do here.
>>>
>>>>>
>>>>> 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.
>>>
>>>
>>> Yea, good point.  Will make them agree.
>>>
>>> I put up the D-Bus interface at
>>> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/11934/ 
>>>
>>>>>
>>>>> 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
>>>>>
>>>
>