Re: sudo not suitable for multi-machine systems
In previous mail, Christoph Lameter wrote:
|
| On Thu, 21 Nov 1996, Ian Jackson wrote:
|
| ian >These programs should be ordinary binaries, and if a sysadmin wants to
| ian >have a local policy that says users X and Y may do Z then sudo is the
| ian >right tool for the job, or they can write a wrapper and put it in
| ian >/usr/local. The setuid bit is _not_ appropriate here.
|
| I dont have one machine. I have a whole set here and the problem to
| administer them. I cannot worry about configuring each machine separately
| to simply have our system administrators perform network diagnostics. Each
| machine has different issues cannot use the same configfile on each
| machine.
Umm, isn't this what the host specification in sudoers rules is for?
A sudoers rule only applies if the current host matches the rule's host
spec, which can be either a hostname, netgroup, ip address, network
number, network number/netmask, or host alias (which lets you have a
list of the above). Thus you can have different access control
configurations for different machines on your network, all in the one
sudoers file.
In any case, if a package contains programs which requires super-user
privileges to work, I'd rather a package not tell me what scheme to use
for access control. I'm not even consistant with what access controls I
use myself! For example, for PPP I have been using the "-rwsr-x---"
approach, using group dialout. But for building Debian source packages,
I have been using sudo.
Access control policy is a local issue, and its up to the local
administrator to decide what to use. My previous sysadmin at work used
sudo religiously, while my current one is working to phase sudo out.
They both understood the implications of sudo. Is one of them "wrong"?
I don't believe so.
My preferred solution is have a document installed with the base system
which discusses the various alternatives objectively (or at least
attempts to). Any packages which contains programs needing super-user
privileges should warn the installer of the fact, and point to the
documentation what the installer can do to give the "right" users the
ability to run them. It's not as automated as many of you would like,
I'm sure, but it leaves the choice with the installer.
(I'll admit tho that it'd be nice if a program's suid-bits can be kept
on upgrades, for the installers who chose to use the suid method after
the initial package installation)
If package installers need to fight your package to have things work
the way they like, they're more likely to abandon the package system
and install from the original sources. I know I would.
Remember there is a final form of control on who can run such programs:
typing in the super-user password. In the end we can only encourage
Debian "admins" to be conscious of the security issues: they alone are
responsible for their hosts' security.
Cheers,
--------------------------------+-----------------------------------
Dennis Clark | Email: dennis@ilanet.slnsw.gov.au
Programmer, ILANET | Tel: +61 2 9230 1439
State Library of NSW | Fax: +61 2 9232 8701
"Help save the world!" -- Larry Wall
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: