Rob van der Heij wrote:
On Mon, Jan 19, 2009 at 5:52 AM, Alan Altmark <[email protected]> wrote:

It isn't about passwords, per se.  Rather, many (most?) sites prohibit
remote login of root *by any means*.

The sad thing about such directives is that they live much longer than
the person who initially dictated them (and still might know the
motivation behind this). Once such rules are established, you can't
easily change them anymore.
The two-step approach for root login has nothing to do with
encryption. When you have a plain old telnet session, the root
password that you type still travels over the wire to the system.
The motivation behind the two-step approach is a poor man's approach
to separate authentication and access control. When someone leaves the
department he may still remember the root password, but if you take
away his local account so that knowledge is less useful to him. But
when the root password is commonly known, then the added value of it
is minimal.

_THAT_ is a major flaw in how RHEL is administered. My wife, who has
CentOS 5 on her desktop gets notified of available software updates.

I am not giving her root's password, she has no idea of how to care for
and feed penguins. It would be much better if the sysadmin (me) was
either informed by her system sending me email, or even just left to me
(her's isn't the only CentOS5 system here).

Red Hat expects every administrator to know root's password.

I think "sudo" asking for the root password is in the same range of

That is how SUSE configures sudo, but it's not its default modus
operandi. By default, it asks for the users' own.

SUSE expects every administrator to know root's password.

useless rituals that create the illusion of security. And when you
logged on to the system, asking again for your password is of little
value (more likely to be picked up by the user watching over your

If I give you a program that does evil if run as root, and if there is
no dialogue with you (asking for a password) before it's run, what
prevents it? We're back with the Windows 95 security model.

shoulder). When you're concerned about sessions remaining unsecured
open too long, then address that (by locking the workstation). I don't

Assuming you've kept your password properly secret, requesting your password
1. Ensures you know Something Important is about to happen
2. You approve it.

have high expectations of per-command access granularity implemented
in sudo. But I do appreciate it for the auditing. When you use LDAP to
associate users with groups, it is very easy to handle access control
for sudo as well.

When dealing with folks who need to work in emergency situations
(doctors, system programmers), attempts to limit their access often
creates a lot of discussion (and for a good reason). Those are no
routine tasks and you can't predict all steps needed. In those cases,
I believe strongly in fairly open access for approved staff, combined
with auditing (and justification afterwards). The auditing is also
helpful to diagnose problems and learn from the steps followed to
resolve the problem. System programmers using their access to tamper
with the auditing should be handled with care.

Rob (amateur security weeny)

On a typical Linux PC, might take me as long as five minutes to get past
root's password.

BIOS and/or bootloader passwords make it more difficult, I have to take
the disk out and install it in another machine.

Encryption would probably stop me, but if I'm your sysadmin you cannot
encrypt any filesystems I might need to access, unless someone else is
on hand when needed.

Which all goes to say a system that's good enough to keep the bad
(local) people out's also going to make legitimate work very difficult.


--

Cheers
John

-- spambait
[email protected]  [email protected]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to