Date: Sun, 6 May 2001 09:14:24 +1000 From: Sue Blake <sue@welearn.com.au> To: Laurence Berland <stuyman@confusion.net> Cc: Jonathan Fortin <jfortin@akalink.com>, "Jonathan M. Slivko" <jslivko@jeah.net>, freebsd-questions@FreeBSD.ORG Subject: Re: Disabling The Root Account Message-ID: <20010506091423.N220@welearn.com.au> In-Reply-To: <3AF48067.76ABD833@confusion.net>; from stuyman@confusion.net on Sat, May 05, 2001 at 05:36:23PM -0500 References: <20010502142336.I30799-100000@awww.jeah.net> <00ba01c0d340$6f1097e0$0200320a@node00> <20010503061301.B6584@welearn.com.au> <3AF48067.76ABD833@confusion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 05, 2001 at 05:36:23PM -0500, Laurence Berland wrote:
> Sue Blake wrote:
> > On Wed, May 02, 2001 at 03:45:25PM -0400, Jonathan Fortin wrote:
> > > No.
> > > What if someone gets a hold of your password, he wouldnt even need root
> > > password to have root access. he would just call /bin/sh via sudo and bam!
> > > sudo has it's pros and what you would be doing is a con.
> >
> > Well, you do have to understand what you're doing when you configure
> > sudo and when you dish out privileges, even to yourself. You also
> > have to change the way personal passwords are treated. Otherwise
> > don't use sudo, or root for that matter.
>
> But either a) you set your sudo policy once, and never again OR
> b) your user can edit the sudo policies. If so, they'll just add
> /bin/sh to the configuration.
>
> Or am I missing something?
Yes, the catch is that it is futile to use sudo as a substitute for
the wheel group and just give blanket access to each of the good guys.
Give them access to those specific commands that they need. In
particular, dissalow access to the visudo program and make sure they
can't edit the file directly, including as an argument to an allowed
command. You can even disallow visudo even for those who have access to
everything else, and they know circumvention attempts would be referred
to the hard copy rules of behaviour and the shot gun in the corner.
For example, people whose job it is to add users or virtual domains all
day just have sudo access to a couple of commands. Assistant admins can
be given root access to almost everything EXCEPT a few commands like su
and the shells (defined then marked like !THIS). See the example
sudoers file and its man page for ideas.
People who need broader access to administer and trouble-shoot in your
absence are a little trickier. But for starters you already trust them
somewhat, and also they know that the beginning of any agreed forbidden
practices will be logged (eg sudo /bin/sh if you forgot to disable that
one for them).
You can even put the sudoers file under RCS and have a cron job to
periodically email an rcsdiff of the current file's contents to you,
then restore the approved sudoers from RCS. Put a commented warning at
the top of sudoers file to the effect that changes will NOT stick
unless they use RCS to register them and to add a change log. Anyone
who can't pick up RCS from the man pages probably can't pick up enough
to go on a rooting spree either, let alone untangle the sudoers file.
Those who you trust to run visudo in an emergency can do so in such
a way that their changes will survive or be temporary ad lib, and
you'll see what they've done.
You're right, like most security tools, using sudo can be more
dangerous than not, if you don't use it the way it is intended with
some careful planning.
--
Regards,
-*Sue*-
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010506091423.N220>