[849] in linux-security and linux-alert archive
Re: [linux-security] sudo limiting
daemon@ATHENA.MIT.EDU (JaDe)
Tue Jun 25 17:59:22 1996
From: jadestar@netcom.com (JaDe)
To: blue@buttercup.cybernex.net (Blue)
Date: Mon, 24 Jun 1996 14:13:14 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199606182119.RAA20576@buttercup.cybernex.net> from "Blue" at Jun 18, 96 05:19:49 pm
>
> Greetings,
>
> The recent thread on sudo has brought a question to me for practical usage.
>
> How to implement administrative accounts which have the permission to
> create or change passwords of arbitary users, without having access to
> change the root password.
>
> I was implementing user adding facilities for a small group whom still
> should not have root access via sudo and realized that they could just
> change the root password. I am loathe to do it with a setuid program,
> even though then I can run the username through a filter, due to the
> probelms having a program like that can create.
>
> Baring hacking passwd, or creating a restricted version of it, is there
> any secure way around this delima?
One point I've made about sudo is that you should only
delegate the authority to people you trust -- people
you'd *almost* trust with the root password itself.
The value is that their actions are trackable (particularly
if you syslog to a remote machine). They leave an
audit trail. They can't change root's password, shell
to root and *change it back* (which 'sudo -c vipw'
would do BTW)
You could certainly have sudo allow access to a
script -- possibly a taint perl script that does
something like:
if ($1 != "root" && $1 != "toor" ) then
su -c 'passwd' $1
(only with more restrictions on $1 to limit it to
a filename -- no IFS type exploits allowed).
That leads me to the real question I had about sudo.
How can I ensure that sudo executes in a sensible
environments (no weird IFS or settings to change
which shared libs are dynamically loaded etc)?
> Jim "Blue" Carstensen
> SysAdmin for Cybernex Inc.
> blue@cybernex.net
