Didier Kryn <kryn@???> writes:
> Le 29/07/2015 16:35, arnt@??? a écrit :
>> Every last problem of sudo is taken seriously? Did you know that if
>> someone has limited access, e.g. the right to install standard
>> packages, then it is easy to leverage that to get complete
>> access. Various packages run programs in $PATH as root, Firefox
>> comes to mind, so just prepare $PATH and sudo apt-get install
>> firefox.
>>
>> Sudo leaves the user's $PATH and the rest is just a matter of
>> finding the right exploit.
>>
>> Was open for years, may still be open.
>>
>> Arnt
>

>     I don't understand the preventions against sudo. It is just up to
> the administrator to take care, like for everything.

>

>     Wether execution of the command is allowed by sudo, by a setuid
> bit or by policykit does not change the result. Sudo is simply the
> most versatile method to allow/disallow actions, IMHO far easier to
> configure than policykit. Don't forget that allowed commands may
> (should) be specified with their absolute path, therefore bypassing
> PATH.

According to some tests I did yesterday, sudo (at least the Debian sudo)
won't allow specifying commands without a pathname so that's not an
issue. But according to the manpage, the upstream sudo default policy
wrt the PATH a user happens to be using when invoking sudo is "pass it
one to the command executed by sudo". Should this command, in turn,
execute some other command without an explicit pathname and use one of
the PATH-searching functions to do so, this will effectively allow the
invoking user to run any code 'as root' because he can use a PATH
containing a directory with a suitably named file in it whose contents
can be anything.

But that's no different from any other conceivable way to trick some
program running with elevated privileges on behalf of an unprivileged
user into running arbitrary code, it's just a simple and obvious way to
do so which doesn't require any programming (skills) and the
solution is "Well, don't do that". Also, the Debian default configuration
contains a

Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

which means the user PATH won't be passed on unless someone explicitly
choses to enable it.

The upstream default PATH handling policy is not suitable for an
environment where certain users are supposed to be restricted to
performing specific actions with elevated privileges unless the
corresponding programs don't run other programs they found in PATH but
that's it.