Security Practices question

Mailman List Mirror (Read Only)
1

I have question for the security community on NANOG.

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0

otherwords

jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.

Now, don't flame me over the question, but provide valid pro's or con's
for this practice from your experience.

thank you.

the reason I'm asking is important.

john brown

2

You'd need a tamper-proof host-based IDS monitoring every file to ensure the
user doesn't install any trojans or backdoors. I assume you don't want to
re-install the OS from trusted media every time you rmuser.

Using something like sudo would be a much better idea.

Bradley

3

"John M. Brown" wrote:

I have question for the security community on NANOG.

I confess that I think of NANOG as not being a security community, rather
it is a group of north american network operators. That said, you can find
all sorts of info for the somewhat naive question below by a slightly
judicious use of our friend, Google. That said, and since I'm avoiding work
that I SHOULD be doing, I will answer your Important question.

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0

This shows a certain naivet�, and suggests that you have not heard of truly
useful tools such as sudo. If it's UNIX, sudo builds. Why is this a bad
thing? The first number in your password entry implies USER. Not users.
There is simply no way to tell which of many multiples of people might have
made a change in your system, since the UID is the same for all.

otherwords

jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

I also truly hope that this was just a quick copy by you, and that you are
not truly discussing a system here that allows the password file to
actually contain the password. Please tell me that your password file is at
least shadowed, and that was just a typo.

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.

I will also supply you with a bit of advice, one that I see even using SSH
over the network to my own machines:

"Don't login as root, use su"

Now, don't flame me over the question, but provide valid pro's or con's
for this practice from your experience.

There are no positive aspects to this practice. I suggest that you get the
wonderful red book (now colored purple, last I recall) by Evi Nemeth et al,
and study it thoroughly.

I now return you to the discussion on (wireless and other) security, how
much is too much, and so on.

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Hello John,

Sunday, September 22, 2002, 6:22:11 PM, you wrote:

I have question for the security community on NANOG.

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0

I'm not sure my opinion is learned, but I would say it is a bad idea.
The vast majority of users do not need all of the privileges that
root access provides. The reason that *nix systems have different
users and groups is to give them different levels of access.

In addition, if there are specific programs that need to be run by a
user which require root access and administrator can use sudo
(Sudo) to give faux root access, without
having to divulge the root password.

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.

That is an invalid argument for three reasons:

1. As soon as a user leaves an organization, their accounts should be
deleted -- that should be SOP at all companies. If you do not allow
the root account to connect directly (ie you cannot SSH to the server
directly as root -- you have to connect as another user and su) when
you delete the user's account they cannot gain root access.

2. You should be rotating your root password often enough that users
would be accustomed to a password change.

3. The only users who should be able to gain root access to a system
are those in the root wheel, at the very least accounts in the root
wheel should be monitored closely and rotated in and out of the wheel
as necessary.

Hope this helps.

allan
- --
Allan Liska
allan@allan.org
http://www.allan.org

5

see below

"John M. Brown" wrote:
>
> I have question for the security community on NANOG.

I confess that I think of NANOG as not being a security community, rather
it is a group of north american network operators. That said, you can find
all sorts of info for the somewhat naive question below by a slightly
judicious use of our friend, Google. That said, and since I'm avoiding work
that I SHOULD be doing, I will answer your Important question.

Right, operators sometimes have to deal with the practicl issues of implementing
security. Security wonks don't always have to deal with their ideas :slight_smile:

Yes, Google is a fine resource. Having messages from the community to
reference is also fine for my purposes :).

> What is your learned opinion of having host accounts
> (unix machines) with UID/GID of 0:0

This shows a certain naivet�, and suggests that you have not heard of truly
useful tools such as sudo. If it's UNIX, sudo builds. Why is this a bad
thing? The first number in your password entry implies USER. Not users.
There is simply no way to tell which of many multiples of people might have
made a change in your system, since the UID is the same for all.

I can spell soodoo.. have used it for years, and advocate its use. there is
a hidden agenda here, can't talk about it.

> otherwords
>
> jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

I also truly hope that this was just a quick copy by you, and that you are
not truly discussing a system here that allows the password file to
actually contain the password. Please tell me that your password file is at
least shadowed, and that was just a typo.

I think clear text is the only way. makes it easier to remember your
passwords :slight_smile:

Ok , that was sarcastic. Sorry.. Um, OTP, Kerb, SSH, Shadow, etc are
things I use, as needed, in my networks.

> The argument is that way you don't hav to give out the root password,
> you can just nuke a users UID=0 equiv account when the leave and not
> have to change the real root account.

I will also supply you with a bit of advice, one that I see even using SSH
over the network to my own machines:

"Don't login as root, use su"

Yes, its amazing the number of people that allow this. People with "cred
and respect" in the community.....

> Now, don't flame me over the question, but provide valid pro's or con's
> for this practice from your experience.

There are no positive aspects to this practice. I suggest that you get the
wonderful red book (now colored purple, last I recall) by Evi Nemeth et al,
and study it thoroughly.

I've got Evi's rainbow on my shelf (all editions of this FINE FINE book,
Yellow, Red, Purple I beleive, right next to Dragon Book, well dog eared
K&R (Pre ANSI, and Post ANSI))

thanks for the comments

6

The biggest argument I have against creating accounts with uid 0, is
that even as an admin, I appriciate not always having admin privs.
I know I'm not perfect. I like running most commands as a
non-privileged user, where a bad typo won't cause as much damage. :slight_smile:

A way of getting around this, I suppose, would be to create 2 accounts
per admin user. A normal unprivileged account, and a superuser
account. This gets all of the accountability of having separate
superuser accounts, without some of the bad things. Depending on the
size of your network, and the tools you use, this may increase the user
management work considerably.

Just some thoughts off the top of my head.
Cheers,
Ryan

7

Date: Sun, 22 Sep 2002 15:22:11 -0700
From: John M. Brown

jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

Kerberos. ksu is a good thing.

Ignoring physical ttys on home machines, "insecure" is the way to
go on all ttys in /etc/ttys (BSD).

Eddy

8

I suspect that the "_r" in the login means that there is a regular jmbrown in
the system as well.

I must admit that I do this too. I only do it for people I trust completely
and only when there are two or, rarely, three people with root. That way if
you see a change and you didn't do it you generally know who did.

Also you get slightly better logging on some commands that log the user name
rather than the UID.

Of course, sudo is still better for all of this overall.

9

Hi John,

Haven't seen you in a while. I hope all is well. Maybe I'll make it to a nanog or arin meeting again one of these days.

As these are unix security questions and I've been a principle reviewer of the bible on unix sysadmin (by Ms. Nemeth et al)...

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0

Learned opinion is, it is considered a back door. Period. It's bad enough having to have one login like that.

On all the machines I manage, the (one) uid 0 account is never used. Period. In fact my staff don't routinely even know the root password. If root ever logs in, it is considered a breach. There is no need for it and I've yet to have anyone convince me otherwise in 15 years of doing this. The only time one needs to login as root is in single user mode when the system won't boot otherwise. For that, the root password is written in a sealed location known to all who need to know. If the seal is broken (meaning it was used), the password is changed.

The problems are specifically:

1) Accountability. You don't know who is creating files and running processes. The best you might get are timestamps and source IP on things like wtmp and su logs for gross comparisons. That's not good enough in most cases.

2) How do you know that all programs protecting the "root" account always do so by UID rather than username? That is unless you view the code yourself or test all such mechanisms. E.g., sshd or login that prevents the root account (usually by default) from being logged into directly from the network interface. How about su where you are supposed to be a member or group 0 before you can suid to root? What about home grown code? It would be nice to think everyone was a good little programmer, but you don't know until you actually test every one of those protective mechanisms.

3) There can be unusual and unexpected behaviors. Some may be benign and confusing, others a problem. For example, all the files will appear as owned by "root" in 'ls' regardless of which of the uid=0 users created them (file ownership is stored by uid). See accountability above. Worse yet, your root files may appear as owned by jmbrown_r. It all depends on how your system reads the passwd database as to which name "wins." What home directory is used when a program needs to reference the users' home directory?? You better test this on your rmuser/userdel program, otherwise you may delete your real root home directory when you delete the other users.

4) Have you ever renamed the root account to something else and left it uid 0? Some of us have been unfortunate enough to have this happen by mistake (by someone who shouldn't have had root access). You would be surprised at what it breaks. Try this first.

The bottom line is that the behavior is OS dependent. For example, I just tried this on BSDI and Linux. The BSDI box was pretty well-behaved by maintaining the proper (original) USER environment after su (even su -). On the linux box, once logged in or su'd the account was 100% indistinguishable from root in all respects. However, su without the - option left some original env vars, but not important ones. Using the 'passwd' command changed the password on the root named account, not the user that logged in on Linux, but not BSDI. However, the BSDI box showed jmbrown_r as the user for all root files using 'ls', the Linux box didn't. The behavior between the two OS was completely inconsistent.

In sum, alternate uid=0 accounts are not necessary, problematic, and have OS dependent behavior. So if you are forced into providing them, you should first test each OS on which you are forced to do this. And test thoroughly.

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.

Specious. The counter argument is that you actually HAVE given out the "root" password. The definition of the "root" account is any account with uid=0. The username is not used for determining unix permission levels - which is of course the whole reason you want uid=0. All you've done is associated multiple passwords with _the_ only root account. That just makes it easier to crack. You've also made it possible for many people to change the "root" user password without them even realizing it. That will be fun when your system is toasted and you have no clue what the root password is. Single-user mode won't accept jmbrown_r's password.

If the users to whom you've given such accounts are naive enough to believe that argument, that they don't have the "root" password, they may also be naive enough to share it with their buddies.

There is often an argument that goes something like sudo doesn't fully change all of the user attributes, and that's not enough in some cases. Given that in most environments you can't login as uid=0 regardless of the username, you would su, then the uid=0 accounts (on a well-behaved OS) may not give you any more fully root access than does sudo.

I suspect the reason you are asking this question is because you have someone who is well-respected insisting that it is a reasonable practice. And you must convince your colleagues otherwise with technical information rather than, "s/he doesn't know what s/he's talking about."

BTW, sudo is not a panacea either. It should not be given to anyone you wouldn't trust with the root password. That's because there are too many programs in which you can break out into a shell or otherwise do something unintended. A combination of sudo and suid/sgid wrappers usually does the trick. A well-written wrapper that limits access (e.g., by group) can be preferable to sudo in many ways.

There may still be some (brain damaged imnsho) applications that absolutely insist on being installed as or operating as fully both uid=0 and euid=0. If installation is the only problem, then it should be installed by one who has the root password, because it is going to do something to mess up your OS config anyway. If it wants to operate that way, may *insert deity* help you. Try to talk to some of the app engineers to find out what it needs it for. You might be able to set it up to run in a chroot environment or you might help them find a way to wrap it or run it as a different (uid != 0) user. Often it is really group access it needs, kmem and maybe sys or disk on linux.

Concede only under duress.

...Barb

10

I have question for the security community on NANOG.

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0

otherwords

jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.

This is a really /really/ REALLY bad idea. I had nightmare issues dealing
with a network formerly run by a 'sysadmin' who thought every user that might
need to do something as root should have a uidzero account. I seriously
cannot think of ANY scenario, no matter how improbable, in which what you're
suggesting would be a good idea (or even defensible).

Now, don't flame me over the question, but provide valid pro's or con's
for this practice from your experience.

Names on accounts are strictly an abstraction to make interacting with the
system easier for us dumb humans. In reality, there is only one UID 0, no
matter how many copies of it you make. This means there is NO difference
between giving out the root password to everybody, and giving everybody UID 0
accounts. None. As far as the system is concerned, the two are one and the
same.

thank you.

the reason I'm asking is important.

Even were it not, I'd still urge you - please do not consider this a valid
option.

11

[snip]

> > I have question for the security community on NANOG.
> >
> > What is your learned opinion of having host accounts
> > (unix machines) with UID/GID of 0:0
> >
> > otherwords
> >
> > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh
> >
> > The argument is that way you don't hav to give out the root password,
> > you can just nuke a users UID=0 equiv account when the leave and not
> > have to change the real root account.
>
> This is a really /really/ REALLY bad idea. I had nightmare issues dealing
> with a network formerly run by a 'sysadmin' who thought every user that
> might need to do something as root should have a uidzero account.

That's not the issue, however.

The assumption is that you have several people who really are fully
qualified admins on the system in question, who really do need full
privileged access. The choice John describes is between giving these
trusted sysadmins the password for "root", or giving them (and them
alone) a UID 0 account as he describes (except that one would of course
use shadow passwords etc.)

Wrong. The choice is between having a single password for the user with id 0,
and having multiple passwords for that same account. This is an abysmally bad
idea, and shame on anybody encouraging it. See

12

[snip]

> > This is a really /really/ REALLY bad idea. I had nightmare issues dealing
> > with a network formerly run by a 'sysadmin' who thought every user that
> > might need to do something as root should have a uidzero account.
>
> That's not the issue, however.
>
> The assumption is that you have several people who really are fully
> qualified admins on the system in question, who really do need full
> privileged access. The choice John describes is between giving these
> trusted sysadmins the password for "root", or giving them (and them
> alone) a UID 0 account as he describes (except that one would of course
> use shadow passwords etc.)

Wrong. The choice is between having a single password for the user with id 0,
and having multiple passwords for that same account. This is an abysmally bad
idea, and shame on anybody encouraging it. See

(mail client sent message while I was editing it; full reply on its way.)

13

[snip]

> >
> > I have question for the security community on NANOG.
> >
> > What is your learned opinion of having host accounts
> > (unix machines) with UID/GID of 0:0
> >
> > otherwords
> >
> > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh
> >
> > The argument is that way you don't hav to give out the root password,
> > you can just nuke a users UID=0 equiv account when the leave and not
> > have to change the real root account.
>
> This is a really /really/ REALLY bad idea. I had nightmare issues dealing
> with a network formerly run by a 'sysadmin' who thought every user that
> might need to do something as root should have a uidzero account.

That's not the issue, however.

The assumption is that you have several people who really are fully
qualified admins on the system in question, who really do need full
privileged access. The choice John describes is between giving these
trusted sysadmins the password for "root", or giving them (and them
alone) a UID 0 account as he describes (except that one would of course
use shadow passwords etc.)

Wrong. The choice here is between having one password for the account with
uid zero, and having multiple, equally valid passwords for that same
account. This is an abysmally bad idea, and shame on anybody that encourages
it. See Barb Dijker's reply in this thread for more details on why.

To put it in other terms, the choice being presented is between several
fully authorized sys admins sharing a single password for "root", or for
each of them to have a unique password, known only to them and shared
with nobody. These are the people who would have full privileged access
on the machine in any circumstance; the only issue is how they get that
access.

Still wrong - with multiple entries in /etc/passwd sharing a single UID, you
end up with multiple passwords for the same exact user, as far as the system
is concerned. The name placed with that user id is strictly a human
convention - to the system, it's all the same user, multiple aliases
notwithstanding.

In my past life working in a classified research facility, the following
policy was strictly enforced: every sysadmin had a user level account
and a root-equivalent account, and all normal work was done from the
user-level account; direct logins to the root-equivalent account were
disabled, so under normal circumstances the only means of getting uid 0
access was through a user level login followed by an su to a unique
account; the password for "root" was locked in a vault, and could only

which was a waste of time - every account with a UID of zero already HAD a
password for root. In the case mentioned, root had not one but one + (number
of non-root uid zero accounts) passwords, all equally valid. (Unless of
course the system in question was running some bizarre version of UNIX
dissimilar to every other I have seen.)

be retrieved in an emergency via a signout procedure, after which the
password was changed and a new one was put in the vault -- in practice
nobody used the "root" account for any purpose, except in emergencies.
In this environment sudo was used heavily, as well -- these
root-equivalent accounts were only for the sysadmins who had full access
to the system -- there were other admins who used sudo to handle many
routine system management tasks.

There is no reason to have multiple UID zero accounts. In the very best of
scenarios, it's a horrible kludge and an excuse for lazy admins to avoid
using sudo properly. That's in the _best_ of scenarios.

This policy was arrived at after a lot of discussion, and it provides
some significant advantages. Most importantly, it allowed much better

I would _love_ to hear what advantages this provided.

management of privileged access: in a large facility systems get added
and modified frequently, sysadmins change responsibilities, emergencies
happen; and you can very easily get to a point where it is hard to know
just who currently has the password to the username "root" account.

Every individual with an account that has a uid of zero had the root
password. Again, see Barb Dijker's mail for more on this.

(Fundamentally, all the arguments agains normal users sharing passwords
apply with even more force to passwords for privileged accounts.)

Absolutely so - which is why no account should have multiple equally valid
passwords, which is what multiple accounts sharing a uid equates to.

Use sudo, use ssh keys from a central admin host, use ACLs - use whatever you
like, but please don't create multiple aliases for an account and think it's
anything but an invitation to disaster.

14

[ On Wednesday, October 2, 2002 at 11:47:12 (-0700), Scott Francis wrote: ]
> Subject: Re: Security Practices question
>
> Absolutely so - which is why no account should have multiple equally valid
> passwords, which is what multiple accounts sharing a uid equates to.

Hold on a minute. You've taken this entirely out proportion for any
reasonable real-world scenario!

that last should have been qualified s/no account should/the root account
should not/

It's _NOT_ that bad. Not anywhere near.

The only real risk with having multiple superuser (UID == 0) accounts is
when the system has some form of vulnerability which makes it reasonable
for an attacker to guess the password. Now normally on any decently
modern system the group of potential attackers who could even begin such
an attack is limited strictly to those who are already members of the
"wheel" group, and all of those people should already have the real root
password anyway.

grr. Please read Barb's post about exactly why multiple aliases for the UID 0
account is a Bad Idea. It's not really about opening potential security
vulnerabilities as much as it is about bad (lazy) administration.

The risks that a wheel-group member will execute a trojan of some sort
that will help an attacker gain increased privileges are much higher
than any of the risks directly associated with multiple UID==0 accounts!

Rubbish. There are no risks associated with members of gid 0 that are not
also associated with accounts having UID 0 - and multiple accounts with UID 0
brings in a host of other issues and problems.

Different UID==0 accounts can have different home directories, and with
careful implementation of certain tools the benefits of this mechanism
also vastly outweigh the risks of having multiple UID==0 accounts.

bah. There is _nothing_ one could reasonably hope to accomplish by creating
multiple accounts with UID 0 that could not be accomplished at least as
easily, and vastly more safely, using sudo.

(before anybody uses it as a defense, yes, there are a (very) few systems out
there that sudo will not run on. That's not the debate here.)

Even just the benefit of being able to appease multiple human superusers
with the abillity to specify different shells for their superuser
account can be enough of a benefit to oughtweigh the risks (though of
course with a small amount of training in the proper use of 'su', there
really isn't any need to specify different default shells in the first
place).

su isn't even needed. USE SUDO. I cannot believe that there are so many
otherwise clueful people out there that apparently are unfamiliar with the
fine-grained control and flexibility that this tool gives the admin (multiple
shells, multiple environments, etc. etc. etc.)

You didn't give one solid example of a real-world threat or
vulnerability for having multiple superuser (UID == 0) accounts. Not
one. If you're going to say something is so bad that nobody should ever
do it regardless then you'd better have some damned good solid threat
analysis and risk assessment to back up your claim!

Trying to avoid yelling here. PLEASE go read Barb's excellent post on EXACTLY
why multiple UID 0 accounts are a problem. She details multiple real risks and
problems associated with this practice. I didn't list them because I thought
it would surely not be too much to ask for those posting to the thread to READ
the thread first, from the beginning. It's not that long.

The only thing you really said that stands up to analysis is your
repeated assertion that multiple accounts with the same UID are, from
the system's perspective, simply multiple ways to authenticate access to
the same underlying system ID and thus to grant exactly the same
authorisations. That is 100% true. What this really means, especially
if the UID in question is zero(0), is that ultimately all activities
that take place on the system are done with that unified UID and so
there's no way to hold separate human users accountable for their
actions. However in the case of UID==0 that's more or less true of 'su'
even with just one "root" account. You have to trust superusers 101%,

I never advocated using su. *sigh* Use sudo.

regardless of how they authenticate to the system. In turn they, if
there's more than one of them, must each be held equally responsible for
any and all damage done by any superuser. If nobody confesses you can

Yes, there is trust that must be given along with superuser privs. The level
of trust required can be MUCH LOWER using sudo, ACLs, or some other system.
As opposed to just giving $admin or $user a blank check to do whatever they
please. There was an excellent talk on exactly why the UNIX permissions
scheme is archaic and needs to be replaced at ToorCon last weekend
<http://www.toorcon.org>, but this is getting off-topic (even for this
thread).

point fingers just as easily with 'login' logs as you can with 'su'
logs, but in the end you cannot prove anything with those logs alone if
its UID==0 (unless the logging is done securely in such a way that
UID==0 cannot modify it). The finger pointing suggested by the logs
_MUST_ be corroberated with an external verifiable alibi (or hopefully
multiples!) (which, BTW, is essentially what any secure logging system
is, and it doesn't matter if 'login' or 'su' generates the audit trail).

USE SUDO. Most people, even those with a legitimate need for superuser
privileges, do not really need the ability to do EVERYTHING on the system as
UID 0. Sure, it takes a bit more effort to setup, but I don't think anybody
could argue that the gains in control, logging, security and
authentication/authorization are not worth it.

Use sudo, use ssh keys from a central admin host, use ACLs - use whatever you
like, but please don't create multiple aliases for an account and think it's
anything but an invitation to disaster.

Sudo is a far worse solution, with a far higher false sense of security,
than multiple UID==0 accounts, unless maybe you're using it purely and
only for convenience and documentation purposes amongst a group of
mutually trusting users who already each know the "real" root password
anyway.

Can you back up that statement in /any/ way? What exactly are your reasons
why sudo is a worse solution (or even a bad idea)?

15

It's my opinion that security, especially when throwing around accounts with
unlimited privileges on a system, matters. If you think differently, well,
you have a right to that opinion as well.

Apparently I will have to quote verbatim from her previous post.

16

Can you back up that statement in /any/ way? What exactly are your reasons
  why sudo is a worse solution (or even a bad idea)?

In an environment where every sysadmin is interchangable, and any one
of them can be woken up at 3am to fix the random problem of the day,
you tell me how to manage 'sudoers' on 4000 machines.

In an situation where the team needs root; all per-admin UID 0
accounts add is accountability and personalized shells/environments.

Sorry to ruffle your dogma.

--mghali@snark.net------------------------------------------<darwin><
   Flowers on the razor wire/I know you're here/We are few/And far
   between/I was thinking about her skin/Love is a many splintered
   thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

17

Date: Wed, 2 Oct 2002 17:48:16 -0700 (PDT)
From: just me

In an environment where every sysadmin is interchangable, and
any one of them can be woken up at 3am to fix the random
problem of the day, you tell me how to manage 'sudoers' on
4000 machines.

krb5/ksu

Eddy

18

Have I missed something here?

It seems to me having multiple uid 0's would do no good.

Can't a UID 0 user change the password of any other user.

Wouldn't a malicious uid 0 user just change the regular root password?

How does this add any additional layer of accountability. A uid 0 user
can erase the logfiles, unless they are immutable and you are in secure
mode.

Jason

19

rdist comes to mind...

20

In an environment where every sysadmin is interchangable, and any one
of them can be woken up at 3am to fix the random problem of the day,
you tell me how to manage 'sudoers' on 4000 machines.

Sudo provides for one master sudoers file that you can copy verbatim to any number of machines. The syntax allows for entries to apply to all machines, groups of machines, or a single machine. If your sysadmins are really interchangeable, you don't even need that syntax. Your sudoers file is a simple ALL=ALL for all sysadmins on all machines. If you really have 4000 machines, sudoers is not the only file that is common and needs to be distributed among them.

In an situation where the team needs root; all per-admin UID 0
accounts add is accountability and personalized shells/environments.

All UID=0 accounts are one and the same. There is NO accountability whatsoever different than everyone logging in as root...

   - if allow login across the net via ssh or telnet to uid=0 (shame on you, btw), the identity of the user on the other end of the session is not logged - could be anyone. wtmp might log the unique username instead of "root", but it might not depending on the OS.

   - if you su, the identity of the user who did the su is logged, so you don't need a separate identity for the account to which they su - may as well just su root.

Once someone is uid=0, via login or su, there is no accountability whatsoever to tie actions to a person. Sudo gives you that in the sudo log.

In unix, accountability is tied to an account. A unix account is one that has a unique UID. All accounting is unix is by UID, not name. Usernames are translated at the time of interpretation from UID. The only time that is not true (poorly written application code not withstanding) is during the login/su sequence as a convenience to the user, so they don't have to know their UID. The only remnant of the username after login/su is in the environment variables of the shell... which can be changed by the user!!!!!

Please refer to my post on this subject dated 9/23.

...Barb