[sudo-users] refusing to execute programs with bad perms

[Micha]

David Thiel <lx at redundancy.redundancy.org>:
| One of the well-known problems with developing an effective sudo policy
| is that if someone is given write permissions to a file, and then
| permission to execute that file as another user, they can effectively do
| anything as that user. 

Isn't that true for root permissions too ?

| In a large environment, it can be hard to keep track of the ownership
| of things like init scripts on various machines. Would it be possible
| or desirable to have a sudo option to refuse to execute a binary or
| script that's writable by the current user? 

I think that's what a properly configured system should care for,
or the sysadmin. It would be a good idea to have some warning
about such occurence, though, when running visudo....or maybe 
implemented in general security checkers, like tiger.
I don't think there's any binary on my system (debian) that a user,
even a system one, can edit, except for root.
And if there's a custom script editable for a specific user then
because he is fully trusted in this respect.
Under any different circumstance, i would work with including user 
configs in such scripts, instead of making something writable.

| Can anyone else think of an alternate way to solve this problem? 

>From following this list since only a few weeks, i got the impression
to have wrapper scripts is a frequent solution to various problems.

Well. It's generally hard to secure a system against hacking from
a login account...usually it starts, IMHO, with downloading some 
malefic tools. Then there is the problem with root access.
I didn't try, but SELinux seem to have an answer here.
Maybe chroot ("kiosk") or virtual systems ("vmware") too.
Anyway, it's a good idea to run something like tiger regularily.

hth



ps. cool domain ;) 

(how about redundancy at org.org ?)

.... and:

Recursion n.: See Recursion.  ( Random Shack Data Processing Dictionary )