Is my implementation/understanding of SUDO flawed?

ian Laing ian.laing at btinternet.com
Sun Feb 24 14:56:05 EST 2002


Hi,

I'm not sure this is appropriate to this group but here's my position (sorry
for the length of this).

OS: AIX 4.3.3  sudo: V1.6.3.6 (downlevel I know but doesn't affect the
position, I think)

We have 24*7 operators who need to be able to stop/start lots of Oracles and
other apps/business
processes and run several bespoke backup scripts. All of which need to run
as root.

We don't want to (but could) make them UID=0 but would rather restrict them
to only being able to
start/stop apps and run those scripts which we want them to run and nothing
else.
The *scripts* to allow them to do that are all in one directory and so I've
downloaded sudo and
permitted them to run as root *everything* in that single directory.

Great... all works as expected... all they can do is run the set of specific
start/stop scripts,
no-more-no-less.

But I've hit 2 fundamental problems with what I'm trying to achieve

1) The start/stop scripts don't sanitise the PATH, so if an operator starts
with a PATH containing
their personal home directory *first* then that is the PATH the scripts use.
They can therefore subvert commands like echo with their own version and
Unix will run that.
Their own echo command can then simply contain a ksh to give them a root
shell.

Solutions would include:
a) explicitly set a know path at the top of every script, OR
b) use absolute paths for every-single command in the script
(/usr/bin/echo), OR
c) set sudo's secure_path setting to override their PATH (but secure_path is
being removed I hear).

The next issue is more of a concern.

2) Many of the start/stop scripts simply call other scripts, which call
other scripts, which call other
scripts and what I'm wondering is, "are any of those writeable by our
operators?"
If they are then there's nothing stopping them adding extra commands to
those lower level scripts
and any of those "sub-scripts" are being run as root.

I was at least hoping to find a parameter/switch/default to at least stop
anyone running a command
via sudo which *directly* allows them to either edit that command or delete
that command and create
their own (ie directory permissions which allow deletion even where file
permissions don't allow update).

If sudo is configured to allow operators to execute as root the commands in
/mydir then I was hoping
some way to tell sudo DON'T LET THEM RUN ANY COMMAND WHICH IS WRITEABLE by
them? but it seems I can't stop that behaviour?

Solution, I suppose, is to regularly check the file permissions in that
directory, but there is a chance
someone will add a script with "soft" file permissions or the wrong
ownership.

Am I fooling myself that sudo can help in a situation like this - other than
me copying all lower level
scripts into one directory where I can check the contents and file
ownership/permissions.

I strongly suspect the latter, as there is no guarantee that somewhere down
the chain there isn't a script
containing a vi command, a more command, a mail command, a smit command etc
which would allow
a shell escape.

Is is ever "safe" to sudo scripts rather than programs?
Using sudo for our operators is slightly better than giving them UID=0 *but*
it tends to give the
false impression that we have some form of *controlled* delegated  authority
where really we
seem to have very little.

How does everyone else manage to safetly sudo their scripts?

Cheerio,
ian Laing





More information about the sudo-users mailing list