Date: Wed, 10 Jul 96 07:33:22 -0700 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: Brian Tao <taob@io.org> Cc: FREEBSD-SECURITY-L <freebsd-security@freebsd.org> Subject: Re: sudo Message-ID: <199607101433.HAA18963@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Tue, 09 Jul 96 20:08:28 EDT." <Pine.NEB.3.92.960709200721.18177A-100000@zap.io.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607101433.HAA18963>