[PATCH] su: support denying accounts with blank password

Denys Vlasenko vda.linux at googlemail.com
Wed Oct 14 08:45:49 UTC 2015


On Wed, Oct 14, 2015 at 8:37 AM, Natanael Copa <ncopa at alpinelinux.org> wrote:
>> On Mon, Oct 12, 2015 at 12:07 PM, Natanael Copa <ncopa at alpinelinux.org> wrote:
>> >> I tested
>> >>
>> >> $ su --version
>> >> su (GNU coreutils) 8.17
>> >>
>> >> and it allows su to root w/o asking for password if it is null.
>> >>
>> >> busybox does the same.
>> >> If there is the need to disallow people to be able to log in as root,
>> >> you should set root password.
>> >>
>> >> If you set password hash to an invalid hash, you can even make people
>> >> to be unable to ever login as root - there is no valid password then
>> >> (passwd -l does this).
>> >
>> > And what if you need remote root users to log in with ssh key for
>> > remote administration but in emergency situations you need a local
>> > technician to log in locally?
>>
>> I don't understand the scenario. You propose to set root password to
>> empty string ("root::...") and disallow su to it.
>
> The scenario is that you ship a vpn box/firewall to protect the "local
> technician". Under normal circumstances the local technician never logs
> in or never touch the busybox powered network device. All
> administration happens remotely via ssh, using ssh keys.
>
>> The "local technician" in this scenario is supposed to log in how?
>
> using a screen and keyboard or via serial cable. he logs in as root,
> but is not asked for password or just press <enter> when asked for
> password.
>
>> Why is this good in general? With /bin/login, root with empty
>> password will not ask for password. This doesn't look more secure
>> than well-known password, it's even less secure.
>
> The security is based on physical access. The local technician can log
> in without password. (in theory, if you have physical access then you
> have access to it all anyway). And after all, it is the "local technician"
> the device is supposed to protect anyway.
>
> The only time the local technician may need to log in is if there is an
> emergency. A situation where there is full panic and the local
> technician (which is not technical at all likely) will try fix the
> situation with help from a real technician on the phone.
>
>> Please give more details.
>
> The idea is that if you have physical access, then you can get full
> access anyway, regardless there is password or not.
>
> You can currently set up a box (or lxcontainer) without password. It
> works great, except that if you log in as normal user (remotely or
> local) you can simply do 'su' to get full root access. This means that
> if a non-root service gets compromised (remote exploit), the attacker
> can simply do 'su' and get full root. That means that the privilege
> separation layer is useless and you end up with a situation where all
> services just as well could have run as root.
>
> The simple way to fix that, is to configure su to not work unless root
> has a password.

Basically, you want root to have no password and yet,
you want people to not be able to su to root.

I find this setup strange. You deliberately remove the thing
which was _designed_ to prevent people to become root
(the password), and then you add hacks ("su won't accept
empty password") to plug the hole you just created.

Do you plan to also teach all other utilities to ignore
empty password? ssh, login, ftpd...

For example, login (at least busybox's one) *works from
non-root shell*. You can run it from shell, yes.
It will ask for username, and if user has no password,
it will log you in!

I continue to think that if you don't want people
to log in as root, you should simply set root password.


More information about the busybox mailing list