Re: Ubuntu root password
- From: Nix <nix-razor-pit@xxxxxxxxxxxxx>
- Date: Tue, 20 Jun 2006 23:45:36 +0100
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
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
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
: 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
- Re: Ubuntu root password
- From: Hans Georg Schaathun
- Re: Ubuntu root password
- Prev by Date: Re: Network Share performance
- Next by Date: Re: Changing my discs around
- Previous by thread: Re: Ubuntu root password
- Next by thread: Re: Ubuntu root password