Re: Sudo tricks

John Richard Moser <nigelenki@comcast.net> writes:

> My conclusion is that the only real way to protect against this is for
> bash to look for every binary in your path when you don't specify a
> path; and check to see if any of those binaries is SUID.  If even one
> is, it should FLAT OUT IGNORE any aliases or non-SUID matches (to avoid
> PATH=$HOME attacks).  What do you all think?

It won't work. If your non-root account is compromised you can't use
sudo, su (or anything that changes access rights) safely. For example,
you can't be sure what shell are you using.

The password check (or other challenge) does only make sense if the
terminal (on which it's entered: shell and user account count too) and
the machine which checks it (the system) are both secure.

I usually use a term "security level" to show what could in theory
be safe and what can never be safe. For instance, root have higher
security level than others on the same machine. "Trusted" machines
(such as admin's terminal) have higher levels than non-trusted
(multi-user, servers etc.): I can safely ssh from my non-root account
on my secure terminal to root@some.server but the reverse is forbidden.

Switching to higher level is never safe. Switching to lower level _can_
be safe - under conditions.

One can consider root and non-root admin account to have the same
security level, though (with non-root account used instead of root
to limit accidental damage only).
-- 
Krzysztof Halasa