Re: Ubuntu root password

On 20 Jun 2006, Hans Georg Schaathun stipulated:
(Yes, a vague memory springs to mind, of some gnu guru's speech on why
these su restrictions were bad, and why they consequently were removed
from GNU su. However, his concern was not security, I can promise you.
If security is your concern, be it not better to replace GNU su by a
Unix su?)

The default su on most Linux boxes comes from the shadow package, which
does not have GNU su's... pecularities.

The little diatribe is in the GNU coreutils manual, and remains one of
the most amusing examples of RMS in full-out impracticality mode that
I've ever read:

,----
| 22.5.1 Why GNU `su' does not support the `wheel' group
| ------------------------------------------------------
|
| (This section is by Richard Stallman.)
|
| Sometimes a few of the users try to hold total power over all the
| rest. For example, in 1984, a few users at the MIT AI lab decided to
| seize power by changing the operator password on the Twenex system and
| keeping it secret from everyone else. (I was able to thwart this coup
| and give power back to the users by patching the kernel, but I wouldn't
| know how to do that in Unix.)
|
| However, occasionally the rulers do tell someone. Under the usual
| `su' mechanism, once someone learns the root password who sympathizes
| with the ordinary users, he or she can tell the rest. The "wheel
| group" feature would make this impossible, and thus cement the power of
| the rulers.
|
| I'm on the side of the masses, not that of the rulers. If you are
| used to supporting the bosses and sysadmins in whatever they do, you
| might find this idea strange at first.
`----

This is, alas, probably one area where idealism can't triumph, for much
the same reason that we don't leave our front doors open all the time:
there are bad people out there who will take advantage of our trusting
nature to attack us.

Even RMS recognizes this these days; that text is very old and should
perhaps be removed if it no longer reflects his views.

The GNU systems are pretty secure nowadays (using OpenSSH et al). The
days when the passwords were given out to all and sundry are long gone
(perhaps because it got annoying having to reinstall cracked boxes, and
because RMS hates being used as a spam source as much as the next man!)

: > - less vulnerable to attack: local users can't get root access with
: > brute force methods; remote users can't log in as root.

Yes they can. They can brute force the trusted user's password just
like a root password. With hardware access, they can boot off another
medium and give root a password. Which brute force attacks would not
work?

They have to know who the trusted user *is*, first. This is hardly
insurmountable, but it *is* doable.

The shadow password suite has support for locking logins after
sufficient failed login attempts, which would do the trick.

In practice only remote users with shell access are a concern in this
area: most remote attackers will aim for root directly via holes in
daemons, and if they have hardware access you are dead anyway, as you
note (although there's a simpler attack: pull the disk, stick it in
another machine and there's nothing you can do except for whole- disk
encryption via a TPM, which has huge reliability concerns: if your
motherboard dies, you've lost the contents of your disk as well!)

: > - less potential for admin mistakes: you only run essential admin
: > commands with sudo, so you are protected from yourself.

No, it gives _more_ potential for admin mistakes. If you are root through
su, login, or xdm, you know you are root (or at least you should know).
However, since sudo only demands password once,

This is customizable.

you will not necesserily
know if a script or a menu runs sudo. With sudo, you risk being root
without being able to tell that you are.

My autobuilder scripts often gain root access (via a passphrased
single-command ssh key). The key's passphrase is stored in an ssh-agent,
so that I only have to type it in once. I'd call this an *advantage*: I
don't normally care which parts of the autobuilder's work happen to be
being done as root. (It varies to some degree between packages, not
least because some packages demand extra install-time configuration and
some, like Subversion, require make check to be run *after*
installation, not before.)

This is sort of the *point* of scripts: they can abstract the boring
crud away. That a particular phase of an autobuild is being done as root
is definitely `boring crud', much as it is boring crud that whenever
you ssh somewhere, an ssh daemon is doing part of its work as root on
your behalf.

: Another benefit is that there's an audit trail of actions, very useful
: when troubleshooting.

Isn't running su also logged?

That depends on the su implementation. shadow's su (which almost every
distribution uses) logs as auth priority.

Where does this alleged security of sudo come from?

I prefer ssh myself (passphrased keys really *are* secure, dammit:
unless you rubber-hose the passphrase out of me there's no brute-forcing
it). In a sense sudo's advantage is convenience, but it's a substantial
advantage because there are many ways in which ssh is terribly
inconvenient for this application. The most obvious that springs to mind
is that there is only one way to restrict what commands may be run from
an ssh session, command=-restricted keys. You can't easily pass
arguments to such commands: you have to store the commands somewhere
safe (somewhere that only the invoker can write to, and that only the
invokee can read from) or pass them down stdin and have the command read
them. sudo permits far more flexible parameter control.

--
`NB: Anyone suggesting that we should say "Tibibytes" instead of
Terabytes there will be hunted down and brutally slain.
That is all.' --- Matthew Wilcox
.

Relevant Pages

  • Re: shell script automatically logging in...
    ... |> | I'm new at shell scripting and don't really have the time to learn it ... |> | ...Now logged in as root ... | suiting this needs - even changed my sudo editor in the process :-), ... feeding the password into the SSH client. ...
    (comp.os.linux.development.system)
  • Re: rsync as root without ssh as root
    ... Since I keep my backups offsite, I'd much rather also do the backup via ssh. ... root without using a root login. ... Use the --rsync-path option to specify a sudo wrapper. ... That works if everything you copy is readable, but if you're going to copy read-only files you're going to need to invoke rsync as root. ...
    (comp.unix.shell)
  • Re: Is SSH worth it??
    ... Keep in mind you can now sniff SSH ... Because the network traffic in a ssh connection is strongly encrypted ... sudo is a lot more useful in such cases. ... without having to divulge the root password. ...
    (Security-Basics)
  • Re: using ssh authentication with sudo
    ... when using ssh authentication I tend to ssh straight into root. ... I have my sshd daemons configured to only allow root login via keys, no passwords allowed, so it's pretty secure. ... This amounts to the same thing as you are talking about if giving full root access but in case you were trying to use sudo to grant elevated privs to just a few commands, then I would suggest looking at the pam for sudo and seeing if there is a module to allow key authentication. ...
    (SSH)
  • Re: newbie question: which make?
    ... What I've seen of gnu make is bloated ... You buy cc from Sun if you want it. ... You shouldn't be doing user work like compiling as root though. ...
    (comp.unix.solaris)