[ale] SSH attempts

[Michael B. Trausch]

On Fri, 2011-09-16 at 13:55 -0400, Jim Kinney wrote:
> But if you lock the root account you're hosed in emergency run level
> 1. Instead set securetty to only be local console and use sudo for all
> else.

Not true.

If root has a password, then when you boot into emergency runlevel 1,
the init system (or appropriate script) will require that a password is
entered before displaying a root shell.

However, if the root account's password is locked or set to an invalid
value, booting into single user mode will present a root prompt
directly.  It is a safeguard against the very problem that you bring up.

Of course, if you have a malfunctioning system and even init won't boot
up, you can always specify "init=/bin/bash" on the command line.

Either way, you have to have access to the bootloader.  So, for example,
you have to have physical access to the system console, or you have to
have access to the bootloader via the system's serial port (perhaps one
that is also attached to the network and accessible via an IP address).
Once that is satisfied, you can boot the system up in single user mode,
or even by running the shell directly as PID 1.

Of course, if you boot with "init=/bin/bash", you can modify anything
about the environment before you do something like "exec /sbin/init", so
that you can change what init is going to do.  Or you can even bootstrap
a multiple user environment by hand (don't laugh, I have actually had to
do that, albeit only once or twice in my entire career) in order to work
around some otherwise fatal problem.  That is one of the really cool,
awesome things about UNIX like systems.  Such a low-level, manual boot
process simply isn't possible in Windows without making excessively
heavy modifications to the software running the system.  But, I am
digressing here.

The reason that locking root's password doesn't decrease the amount of
security is because you don't need root's password to truly boot the
system if you have access to the boot loader.  Sure, if root has a
password you put a very minor road block in the way if someone attempts
to boot "single", "1", or "emergency".  But they'll just reboot the
system again and swap it out with "init=/bin/bash", and they'll get a
very barebones environment.  Now all you have to do is "openvt
-l /bin/bash" and you have a job-control enabled bash session
on /dev/tty2, and you don't have to worry about a thing.  Maybe remount
the root filesystem read-write, and have yourself a field day.

Now, there is a way to stop all of this:  if you encrypt the drives, you
can specify whatever boot flags you want but you'll never actually be
able to mount the filesystem without the key.  Or you can put a password
on the bootloader so that only someone who possesses the password is
allowed to modify the boot process in any way.  But the normal
situation, unfortunately, is neither---even on a lot of production
systems.

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                  --- Carveth Read, “Logic”