Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Tue, 13 Oct 2015 18:03:10 +0200
Denys Vlasenko  wrote:

> On Mon, Oct 12, 2015 at 12:07 PM, Natanael Copa  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  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.

Ideally, su should also consult /etc/securetty so it becomes a runtime
configuration instead of compile time. I can prepare a patch for that
if you want.

-nc
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Denys Vlasenko]

On Wed, Oct 14, 2015 at 8:37 AM, Natanael Copa  wrote:
>> On Mon, Oct 12, 2015 at 12:07 PM, Natanael Copa  
>> 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  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.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Michael Conrad]

On 10/14/2015 2:37 AM, Natanael Copa wrote:

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.


Why run 'login' at all?  You can just run "agetty -l /bin/bash" from 
init or runit and always have a shell ready.


Alternatively you can randomize the password and print it on the console 
with the welcome message.


Just some other ideas.
-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Laurent Bercot]

On 14/10/2015 08:37, Natanael Copa wrote:

using a screen and keyboard or via serial cable. he logs in as root,
but is not asked for password or just press  when asked for
password.


 What companies usually do in this case (typically ISPs with modems
they ship to users) is set a trivial root password, such as "admin",
and disable privilege-gaining binaries entirely, except /bin/login
which checks /etc/securetty.
 It's not much harder for a non-technical user to log in with a
trivial password than with no password at all, and it ensures that
only local users can log in as root. (Of course, ISPs have their
own backdoors into those modems, but that is another story.)

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Denys Vlasenko]

On Wed, Oct 14, 2015 at 1:52 PM, Natanael Copa  wrote:
> On Wed, 14 Oct 2015 05:43:32 -0400
> Michael Conrad  wrote:
>
>> On 10/14/2015 2:37 AM, Natanael Copa wrote:
>> > 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.
>>
>> Why run 'login' at all?  You can just run "agetty -l /bin/bash" from
>> init or runit and always have a shell ready.
>
> This is a valid alternative approach that has been discussed.
>
> The drawback is that if you actually want a root password you will have
> to edit /etc/inittab while with 'su' you'll only need set password.

How about running "agetty -l /path/to/script_which_execs_sh_or_login"?

#!/bin/sh
grep -q "^root::" /etc/passwd && exec sh "$@"
exec login "$@"
echo "Your PATH is borked, can't find 'login'. PATH='$PATH'"
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Wed, 14 Oct 2015 10:45:49 +0200
Denys Vlasenko  wrote:

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

Correct. The thinking is that empty password is better than a bad
password.

> 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...

yes. ftpd does not run as suid root, right? then it is no problem.

sshd has config options for disallow root at all, disallow password
logins (and use ssh keys only) or disallow blank passwords.

> 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!

There is a config option to make busybox login consult securetty.

The only thing left to teach to ignore empty password is busybox su.
Thus this patch.
 
> I continue to think that if you don't want people
> to log in as root, you should simply set root password.

This feature would be for people who want people to log in as root
locally, while still have privilege separation for network services.

-nc
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Wed, 14 Oct 2015 05:43:32 -0400
Michael Conrad  wrote:

> On 10/14/2015 2:37 AM, Natanael Copa wrote:
> > 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.
> 
> Why run 'login' at all?  You can just run "agetty -l /bin/bash" from 
> init or runit and always have a shell ready.

This is a valid alternative approach that has been discussed.

The drawback is that if you actually want a root password you will have
to edit /etc/inittab while with 'su' you'll only need set password.

This actually matters for me because i want use no password as default
for the alpine linux LXC template. Then you can just create the
container and set password. If you forget the set password step you are
still more or less safe. (sshd default config disallows root login with
empty password).

> Alternatively you can randomize the password and print it on the
> console with the welcome message.

This is an interesting idea.
 
> Just some other ideas.
> -Mike
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Wed, 14 Oct 2015 12:18:04 +0200
Laurent Bercot  wrote:

> On 14/10/2015 08:37, Natanael Copa wrote:
> > using a screen and keyboard or via serial cable. he logs in as root,
> > but is not asked for password or just press  when asked for
> > password.
> 
>   What companies usually do in this case (typically ISPs with modems
> they ship to users) is set a trivial root password, such as "admin",
> and disable privilege-gaining binaries entirely, except /bin/login
> which checks /etc/securetty.
>   It's not much harder for a non-technical user to log in with a
> trivial password than with no password at all, and it ensures that
> only local users can log in as root. (Of course, ISPs have their
> own backdoors into those modems, but that is another story.)

This is also what many distros do in their LXC templates. Problem is
that users start sshd and sshd does not disable root login with
password by default. So container provider start container and before
user reach to log in to set password they are compromised.

see https://github.com/lxc/lxc/issues/302

-nc
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Denys Vlasenko]

On Mon, Oct 12, 2015 at 12:07 PM, Natanael Copa  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 "local technician" in this scenario is supposed to log in how?

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.

Please give more details.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Thu, 1 Oct 2015 19:39:00 +0200
Denys Vlasenko  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.

su was removed from GNU coreutils since 8.18:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=928dd73762e69cfeaab4a7ec9dd8f30f86a45ed4

It says that util-linux is the new place for it.
 
> 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?

Do you recommend using a default password? eg user 'root', password
'admin'?

How do you then ensure that the privilege separation is effective?
Daemons runs as non-root for a reason: if the service gets compromised
they get only limited access. If a compromised service can just su and
pass a default password, why bother running the service as different
user in first place?

-nc
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Denys Vlasenko]

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).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Alain Mouette]

Why would you want to completely disable root login?

If it is a security feature, how can it be used? It can be interesting 
to avoid escalating priviledges, but then how to to administrative 
tasks? (assuming ssh root login is disabled too)


Thanks,
Alain


On 01-10-2015 14:39, Denys Vlasenko 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).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Jody Bruchon]

On 10/1/2015 2:42 PM, Alain Mouette wrote:

Why would you want to completely disable root login?

If it is a security feature, how can it be used? It can be interesting
to avoid escalating priviledges, but then how to to administrative
tasks? (assuming ssh root login is disabled too)


Ubuntu disables root logins via both 'login' and 'su' and forces the use 
of 'sudo' to run things as root. I assume that this is what people want 
to exclusively use for privilege escalation when suggesting this feature.


In my case, I have a Linux "rescue" platform which has a blank root 
password because it's unnecessary to force the user to type one in and 
the entire system is designed to run temporarily out of a tmpfs. In my 
case, whether this affects 'su' or 'login', it would be a bug, not a 
feature. As long as it is an optional behavior that I can disable with 
no side effects, I see no reason to argue with making such a feature 
available.


Jody Bruchon
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Rich Felker]

On Thu, Oct 01, 2015 at 03:42:40PM -0300, Alain Mouette wrote:
> Why would you want to completely disable root login?
> 
> If it is a security feature, how can it be used? It can be
> interesting to avoid escalating priviledges, but then how to to
> administrative tasks? (assuming ssh root login is disabled too)

Requiring pubkey-based ssh login is the canonical best-practices way.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Kaarle Ritvanen]

On Wed, 10 Jun 2015, Timo Teras wrote:

> On Tue, 09 Jun 2015 22:20:30 +0200
> Laurent Bercot  wrote:
> 
> >   IOW, if a computer gets hacked because its root password was
> > blank or default, it's not a problem you can solve by choosing
> > the other solution. :)
> 
> The only situation that would benefit from this is that you have box
> running network only services (no local logins for users). And admin
> is done with ssh key authentication.
> 
> The problem then becomes: services run as non-root users, and to
> maintain security isolation, you don't want those service accounts to
> be able to sudo or su.
> 
> Having no password for root would allow console login if necessary
> without need to consult password lists. But at the same time disable all
> other root access.

Yes, applying this patch would allow for greater security than setting the 
root password. Passwords are always subject to dictionary and brute force 
attacks, recording by keyloggers, discovery of the Post-it note where they 
are written on etc. This patch, on the other hand, would remove these 
attack vectors completely while allowing root access via a trusted 
console.

In mainstream Linux distributions, the same effect can be achieved by 
adjusting the PAM configuration for su. Having this patch included would 
increase busybox's usefulness without increasing its footprint at all.

BR,
Kaarle
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[PATCH] su: support denying accounts with blank password

[Natanael Copa]

Add a compile time option to disallow switching to an account with blank
password.

Signed-off-by: Natanael Copa nc...@alpinelinux.org
---
A grep showed that all users of ask_and_check_password_extended
compared  0 so this patch should not break anything.

 libbb/correct_password.c | 4 ++--
 loginutils/Config.src| 5 +
 loginutils/su.c  | 3 +--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libbb/correct_password.c b/libbb/correct_password.c
index 513c930..afd307f 100644
--- a/libbb/correct_password.c
+++ b/libbb/correct_password.c
@@ -88,7 +88,7 @@ int FAST_FUNC check_password(const struct passwd *pw, const 
char *plaintext)
 
 
 /* Ask the user for a password.
- * Return 1 without asking if PW has an empty password.
+ * Return 2 without asking if PW has an empty password.
  * Return -1 on EOF, error while reading input, or timeout.
  * Return 1 if the user gives the correct password for entry PW,
  * 0 if not.
@@ -105,7 +105,7 @@ int FAST_FUNC ask_and_check_password_extended(const struct 
passwd *pw,
 
pw_pass = get_passwd(pw, buffer);
if (!pw_pass[0]) /* empty password field? */
-   return 1;
+   return 2;
 
plaintext = bb_ask(STDIN_FILENO, timeout, prompt);
if (!plaintext) {
diff --git a/loginutils/Config.src b/loginutils/Config.src
index fa2b4f8..42b86ac 100644
--- a/loginutils/Config.src
+++ b/loginutils/Config.src
@@ -311,6 +311,11 @@ config FEATURE_SU_CHECKS_SHELLS
depends on SU
default y
 
+config FEATURE_SU_DENY_EMPTY_PASSWD
+   bool Enable su to deny empty passwords
+   depends on SU
+   default n
+
 config SULOGIN
bool sulogin
default y
diff --git a/loginutils/su.c b/loginutils/su.c
index f812505..9cef3a6 100644
--- a/loginutils/su.c
+++ b/loginutils/su.c
@@ -92,8 +92,7 @@ int su_main(int argc UNUSED_PARAM, char **argv)
}
 
pw = xgetpwnam(opt_username);
-
-   if (cur_uid == 0 || ask_and_check_password(pw)  0) {
+   if (cur_uid == 0 || ask_and_check_password(pw)  
(ENABLE_FEATURE_SU_DENY_EMPTY_PASSWD ? 1 : 0)) {
if (ENABLE_FEATURE_SU_SYSLOG)
syslog(LOG_NOTICE, %c %s %s:%s,
'+', tty, old_user, opt_username);
-- 
2.4.2

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Isaac Dunham]

On Tue, Jun 09, 2015 at 01:06:05PM +0200, Natanael Copa wrote:
 Add a compile time option to disallow switching to an account with blank
 password.

And how does one set the root password, if you blank the root password?
Wouldn't this result in a system that's permanently unadministrable
unless you recover via init=/bin/sh, chroot, or such?

Or is blanking the root password completely wrong?

Thanks,
Isaac Dunham

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Laurent Bercot]

On 09/06/2015 16:57, Isaac Dunham wrote:

Or is blanking the root password completely wrong?


 I wouldn't say it's wrong, but it can be easily avoided.
You can always use a trivial password such as root or admin
for an initial machine setup.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Laurent Bercot]

On 09/06/2015 21:44, Natanael Copa wrote:

It is an interesting dilemma. What is worse, blank root password or
weak/default root password (eg 'root' or similar)?


 I'll suggest that it doesn't matter in the slightest, because a
machine should only be in either state when it's on a trusted
network where new machines are installed (or, if possible, on no
network at all) and should never find themselves in those states
out there in a place where users can connect to them.

 IOW, if a computer gets hacked because its root password was
blank or default, it's not a problem you can solve by choosing
the other solution. :)

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Natanael Copa]

On Tue, 9 Jun 2015 07:57:17 -0700
Isaac Dunham ibid...@gmail.com wrote:

 On Tue, Jun 09, 2015 at 01:06:05PM +0200, Natanael Copa wrote:
  Add a compile time option to disallow switching to an account with blank
  password.
 
 And how does one set the root password, if you blank the root password?
 Wouldn't this result in a system that's permanently unadministrable
 unless you recover via init=/bin/sh, chroot, or such?

This does not change 'login' only 'su', so you can still log in via
physical terminal (or lxc-console in case it is a container).
 
 Or is blanking the root password completely wrong?

The idea behind the patch was actually for situations where the root
password intentionally is blank and you log in with an ssh key, or with
physical access.

It is an interesting dilemma. What is worse, blank root password or
weak/default root password (eg 'root' or similar)?

I'd say bad password is worse than blank because default sshd config
will happily let anyone in with a bad password, but will not accept a
blank password. But currently, a blank root password will effectively
make all accounts root accounts since 'su' will let anyone elevate to
root.

-nc

 Thanks,
 Isaac Dunham
 

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Timo Teras]

On Tue, 09 Jun 2015 22:20:30 +0200
Laurent Bercot ska-dietl...@skarnet.org wrote:

 On 09/06/2015 21:44, Natanael Copa wrote:
  It is an interesting dilemma. What is worse, blank root password or
  weak/default root password (eg 'root' or similar)?
 
   I'll suggest that it doesn't matter in the slightest, because a
 machine should only be in either state when it's on a trusted
 network where new machines are installed (or, if possible, on no
 network at all) and should never find themselves in those states
 out there in a place where users can connect to them.
 
   IOW, if a computer gets hacked because its root password was
 blank or default, it's not a problem you can solve by choosing
 the other solution. :)

The only situation that would benefit from this is that you have box
running network only services (no local logins for users). And admin
is done with ssh key authentication.

The problem then becomes: services run as non-root users, and to
maintain security isolation, you don't want those service accounts to
be able to sudo or su.

Having no password for root would allow console login if necessary
without need to consult password lists. But at the same time disable all
other root access.

/Timo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox