Is my implementation/understanding of SUDO flawed?

[ian Laing]

From: "Jeff Kennedy" <jlkennedy at amcc.com>

> I'm thinking that you're asking for capabilities that sudo was never
> meant to handle outside of the path issue.  The way I would tackle this
> is  go through the initial pain to check all the scripts and
> permissions, then setup tripwire to catch any changes to said scripts.
>
> ~JK
>
> =====================
> Jeff Kennedy
> Unix Administrator
> AMCC
> jlkennedy at amcc.com

Hi Jeff,

I have to say I agree with you that I am asking a lot but some people make
the assumption that sudo == security and they can sit back, implement sudo
and delegate authority to run scripts without looking too closely at what
they've let themselves in for (like me, whoops)

However I see sudo just being another tool in the armoury with no inherant
security built-in, like a firewall is just a tool with no inherant security;
if you badly administer it then you might as well not have it (maybe Todd
won't agree wholeheartedly with that but it's just my 2 cents worth).

Strangely enough trip wire *is* on my "shopping list" when I get some spare
time and it's a nice idea to have it backing up sudo to check for any
future unauthorised script/permission changes.

I may be asking a lot but sudo already caters, as you say, for overriding
one's initial PATH and, without looking too closely at the ramifications, I
can see no big reason to think that if sudo meets a *top level* script with
777 permissions then it could simply refuse to run it unless-and-until the
administrator positively accepts that situation with a configuration flag
which says allow "open" scripts to be run.

Am I asking too much? why does sudo handle initial PATH issues within it's
remit (and it doesn't stop a script itself setting an equally awful PATH
selection after sudo initially sanitized it) to help stop a user shooting
themselves in the foot, and then it gives them a cannon to blow the
unsuspecting administrators head off ;-o

Perhaps I'm asking for something which simply re-inforces my false sense of
security, in that it would be near impossible to check all sub-scripts for
open permissions from sudo, so even that cursory check isn't *really*
sufficient; as is the case for PATH which *may* start clean but can't be
guaranteed to *stay* clean unless you can control the scripts.
(or does sudo set a readonly PATH variable, if that's even possible)

In my heart of hearts I know and agree with you that I *need* to consolidate
and take control of all those lower level scripts and having top-level
checking isn't really sufficient so I still need to address the entire
issue.

I think my main problem is introducing sudo after-the-fact for existing
scripts which were not really written with sudo in mind.
Maybe others simply use sudo for self contained scripts which don't call
other scripts, which is where my problems start -- ours do and we've
literally hundreds of top level scripts calling other scripts in lots of
different directories.

In a sense the problem also boils down to one of, without sudo, if I as a
root administrator run one of those scripts can I *guarantee* no-one's
changed any of the commands to do something "naughty" when it's run by root,
so it's not really an issue directly related to sudo.

Sorry for the long reply.

Cheerio,
ian Laing