Disable Local Users Proposal
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.
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.
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
Hi Matt,
Please find my comments inline
Ratan
Quoted 9 lines · Matt Spinler
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_unixmodule from/etc/pam.d/common-authand/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?
Quoted 11 lines
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.
Quoted 11 lines
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
Quoted 15 lines · Ratan Gupta
Hi Matt,
Please find my comments inline
Ratan
Quoted 6 lines · Matt Spinler
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.
Quoted 8 lines
Quoted 3 lines
It was recommended that I do this by removing the
pam_unixmodule from/etc/pam.d/common-authand/or common-account(I think?), and also remove ~/.ssh/authorized_keys if present.By removing the
authorized_keysmeans 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 9 lines
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/
Quoted 11 lines
Quoted 11 lines
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
Hi Matt,
I am not sure, whether you want to permanently disable local accounts or only make it in a configurable way ?
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 ? 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 ?).
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 ? Because even this property can be set to TRUE and then users can be created / configured right ?
Regards,
Richard
Quoted 67 lines · Matt Spinler
Quoted 15 lines · Ratan Gupta
Hi Matt,
Please find my comments inline
Ratan
Quoted 6 lines · Matt Spinler
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.
Quoted 8 lines
Quoted 3 lines
It was recommended that I do this by removing the
pam_unixmodule from/etc/pam.d/common-authand/or common-account(I think?), and also remove ~/.ssh/authorized_keys if present.By removing the
authorized_keysmeans 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 9 lines
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/Quoted 11 lines
Quoted 11 lines
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
Hi Richard,
Quoted 4 lines · Richard Marian
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.
Quoted 6 lines
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/shadowfile 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
Quoted 4 lines
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.
Quoted 4 lines
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?
Quoted 2 lines
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.
Quoted 69 lines
Regards,
RichardQuoted 64 lines · Matt Spinler
Quoted 15 lines · Ratan Gupta
Hi Matt,
Please find my comments inline
Ratan
Quoted 6 lines · Matt Spinler
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.
Quoted 8 lines
Quoted 3 lines
It was recommended that I do this by removing the
pam_unixmodule from/etc/pam.d/common-authand/or common-account(I think?), and also remove ~/.ssh/authorized_keys if present.By removing the
authorized_keysmeans 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 9 lines
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/Quoted 11 lines
Quoted 11 lines
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
Quoted 31 lines · Matt Spinler
Hi Richard,
Quoted 4 lines · Richard Marian
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.
Quoted 6 lines
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/shadowfile 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
Quoted 4 lines
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.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
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).
Quoted 11 lines
Quoted 4 lines
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
Quoted 73 lines
Quoted 72 lines
Regards,
RichardQuoted 65 lines · Matt Spinler
Quoted 15 lines · Ratan Gupta
Hi Matt,
Please find my comments inline
Ratan
Quoted 6 lines · Matt Spinler
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.
Quoted 8 lines
Quoted 3 lines
It was recommended that I do this by removing the
pam_unixmodule from/etc/pam.d/common-authand/or common-account(I think?), and also remove ~/.ssh/authorized_keys if present.By removing the
authorized_keysmeans 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 9 lines
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/Quoted 11 lines
Quoted 11 lines
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