From owner-freebsd-security Wed Jul 10 07:33:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14805 for security-outgoing; Wed, 10 Jul 1996 07:33:41 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14798 for ; Wed, 10 Jul 1996 07:33:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id HAA18963; Wed, 10 Jul 1996 07:33:22 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199607101433.HAA18963@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: sudo In-reply-to: Your message of "Tue, 09 Jul 96 20:08:28 EDT." Date: Wed, 10 Jul 96 07:33:22 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are people's feelings towards the "sudo" utility? Is it > really all that usefull, or does it just open up a lot of potential > avenues of attack and abuse? Some of our co-located customers want to > have it installed so they can do some root-privileged stuff, instead > of getting us to do it all the time (even though that's what they pay > us to do). Where I work we use it all the time. We use it mainly internally within the Open Systems Group (people who would normally have the root password anyway). The root passwords are normally not used and are stored in an envelope in the security services office. We currently have only one client who requires sudo to mount a number of VM/ESA minidisks on a Sun box to load a DB2 database. In this case a we have built some code to prompt the user for various VM specific mount options. The code only allows them to mount VM minidisks from two VM machines on our raised floor. I have seen indiscriminate use of sudo which will compromise a system. For example, vi and more. Granting sudo access to vi is an obvious hole but more is a little subtle. Since you can shell escape in more, granting access to more would grant the user a root shell. To make effective use of sudo with a help desk, for example, you would need to build code to perform the required function while restricting the user's access to other functions. For example, if you wish to have your helpdesk alter end-user's dot files when when your users call in for help, you could create some code to copy the user's dot file to a work area, via sudo, then edit the dot file in the work area, under the help desk person's own id, and finally copy the working copy of the dot file from the work area to the user's home directory. Your code would contain checks to ensure that only end-user's dot files can be updated, not the files of system administration staff. In short, granting root privilege via sudo takes a lot of planning to ensure that all potential security holes are plugged. > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) > Systems and Network Administrator, Internet Canada Corp. > "Though this be madness, yet there is method in't" > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."