From owner-freebsd-questions Sat May 5 16:14:54 2001 Delivered-To: freebsd-questions@freebsd.org Received: from phoenix.welearn.com.au (unknown [139.130.44.81]) by hub.freebsd.org (Postfix) with ESMTP id 0A2E537B43C for ; Sat, 5 May 2001 16:14:41 -0700 (PDT) (envelope-from sue@phoenix.welearn.com.au) Received: (from sue@localhost) by phoenix.welearn.com.au (8.11.1/8.11.1) id f45NEOJ22841; Sun, 6 May 2001 09:14:24 +1000 (EST) (envelope-from sue) Date: Sun, 6 May 2001 09:14:24 +1000 From: Sue Blake To: Laurence Berland Cc: Jonathan Fortin , "Jonathan M. Slivko" , freebsd-questions@FreeBSD.ORG Subject: Re: Disabling The Root Account Message-ID: <20010506091423.N220@welearn.com.au> References: <20010502142336.I30799-100000@awww.jeah.net> <00ba01c0d340$6f1097e0$0200320a@node00> <20010503061301.B6584@welearn.com.au> <3AF48067.76ABD833@confusion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF48067.76ABD833@confusion.net>; from stuyman@confusion.net on Sat, May 05, 2001 at 05:36:23PM -0500 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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