[ On Thursday, September 6, 2001 at 11:31:56 (-0700), Simon J. Gerraty wrote: ]
> Subject: Re: sshd Change: PermitRootLogin = no
>
> I've setup quite a number of machines where all accounts have uid=0
> This allows each admin to have different password (for console access).
> Network login was only allowed by SSL telnet using X.509 certs, but
> SSH would probably have sufficed. I guess you'd call them multi-admin
> boxes :-)

Yes, that's another very good option -- the key point (other than of
course securing the network connection from various types of attack) is
to keep a solid verifiable link between an authenticated user-ID for an
authorised session and the real world user who initiated it.

In some ways this isn't that much different from Kerberos root instances
for every authorised user, or even an honor system of always using sudo.

[[ rearranging your paragraphs here a bit... ]]
> Audit trails (for what they are worth) are not compromised, since the logs
> will show that sjg logged in, and sjg reconfigured blah.

Yes, exactly.  Provided that you've assigned unique X.509 certificates
to each authorised individual then your configuration meets that
requirement.

However....  (there's always a "gotcha"!  ;-)

Where are the audit trails recorded (and how) (and who has acess to the
hardware they're logged on, etc.)?

> All processes on the box, are either privaleged because they are being run
> by an admin who should know, or un-privaleged with no means of escape.

This is another major "gotcha" too --  there are many and varied risks
with running some types of processes with unnecessarily high privileges.
(and not all of them obvious on first glance either -- some of the more
dangerous ones are quite subtle!)

The one thing I really like most about sudo is that it can be used in a
fashion where normally it only runs one command at a time.  (Yes you can
do that with 'su' too, but the need to type a password for every command
is more trouble and risk than simply using a root shell prompt for
general operations.)

Ideally I like to create group-IDs for every major subsystem that
requires regular manual maintenance (eg. mailers, DNS, FTP, UUCP, etc.)
and to give these group privileges to authorised subsystem
administrators.  (Back in my pre-BSD days I had to use 'newgrp' and type
a password to get access to a given subsystem; and we could easily
re-implement that feature for BSD too, though I'm not sure it would
really be worth it since such authorisation is generally a pre-arranged
thing and use of an authentication scheme such as a password is not as
important when it's only the group privileges being excercised and the
same system identity is maintained throughout.  I would though like a
'newgrp' command that would allow me to cycle a different group from the
list into the top/primary position, which in conjunction with an audit
logging mechanism that recorded the whole group membership list in its
current order could show what privileges a user was intending to use at
any given time.)

> Personally I like the idea of allowing "root" logins - though not via 
> passwords.
> So making the default to deniy root authenitcation via password
> would meet that criteria[?

Yes, that's more or less what it boils down to....

Yes, I think it would, assuming of course that the authentication scheme
used to replace passwords required that each individual person had a
unique key/token/whatever.

> (though with ~/.ssh on NFS etc password is the 
> only really safe option that ssh allows :-)  that's the other reason
> I don't like SSH.  That doesn't stop me using it though :-)

Almost all of the workstations on my home office network are X11
terminals and either not capable of running ssh clients internally, or
not powerful enough to do so for general use.  As a result I'm pretty
much restricted to declaring my Ethernet as secure, and thus allowing
SSH to read secret files across NFS is the least of my worries!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>