Re: shared root account
I agree with this assessment of Andreas' - in fact this is what we use in
our organization. Unfortunately we don't have the luxury of fully trusting
admins, so I am a little paranoid about giving out full-on sudo to people,
but this is mostly a personnel issue having to do with the nature of the
industry with which our organization operates.
Having said that we do it this way as well, I'll point out one flaw which
particularly nags at me. Andreas said, "a) allowing convenience by allowing
the user to effectively choose their own root passwd." which roughly
equivicates to the difference between having one root password that can be
cracked to get to the system, to having N+1 root passwords that can be
cracked to get at the system (where N=number of admins with sudo access). At
this point it is a toss up - is the convenience of not having to pass around
the root password to all the admins worth the additional cracks? Do you
trust each admin to be secure with both their password choices as well as
the rest of their actions?
Micah
On Sun, 08 Jul 2001, Andres Salomon wrote:
> This is completely off-topic at this point, but there are a few uses
> of sudo. The original poster trusts his admins, and wants to give
> them all root privs without the hassle of having them all use one
> account. Sudo is not enforcing anything in this case, it is merely
> a) allowing convenience by allowing the user to effectively choose
> their own root passwd.
> b) allowing a form of audit trail; true, it's easy enough to bypass,
> but someone trusted wouldn't go out of their way to bypass it. It's
> good for when (for example) samba suddenly stops working, instead of
> checking /root/.bash_history for "<editor> /etc/smb.conf", running
> `last` to see when root has logged in since it broke, etc etc,
> you simply check your logs for the last time someone sudo'd "<editor>
> smb.conf". Make it policy for admins to not use `sudo bash`, or
> anything similar.
>
> What you people are talking about is adding privs to an untrusted
> account. The (ridiculous) example given, of allowing a user to
> run /bin/cat, is similar doing a `chown root:<untrusted user> /bin/cat;
> chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do,
> if the user needed to view a file, is provide the argument to cat that
> was required. "<username> ALL=(root) /bin/cat /etc/[a-zA-Z]". Or
> specify the exact filename. If it's an untrusted user, they should
> be given as little leeway as possible. Allowing them to cat any file
> on the system is just stupid.
>
> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote:
> > Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400
> >
> > >>>>> "Ethan" == Ethan Benson <erbenson@alaska.net> writes:
> >
> > Ethan> or even seemingly innocuous things like less or even cat.
> >
> > Less is a problem, yes, as is anything else with a shell escape.
> >
> > Ethan> sudo less anything !/bin/sh whoami r00t!
> >
> > Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers'
> >
> > doesn't work. the >> is a shell redirection, but sudo doesn't
> > evaluate in a shell.
> >
> > $ echo me ALL=ALL > s
> > $ cat s
> > me ALL=ALL
> > $ sudo 'cat s > foo'
> > sudo: cat s > foo: command not found
> > $ sudo cat s \> foo
> > me ALL=ALL
> > cat: >: No such file or directory
> > cat: foo: No such file or directory
> >
> > I would be very shocked if you could compromise a system with a
> > sudoers entry of:
> > me hostname = (root) /bin/cat
> >
> > Ethan> sudo is a very large cannon which is difficult to keep aimed
> > Ethan> away from the foot...
> >
> > That it is. But then, the root password is basically a very large
> > cannon built into your shoe.
> >
> > -Eric
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> >
> >
>
> --
> "... being a Linux user is sort of like living in a house inhabited
> by a large family of carpenters and architects. Every morning when
> you wake up, the house is a little different. Maybe there is a new
> turret, or some walls have moved. Or perhaps someone has temporarily
> removed the floor under your bed." - Unix for Dummies, 2nd Edition
> -- found in the .sig of Rob Riggs, rriggs@tesser.com
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: