Le 30/07/2015 11:28, Rainer Weikusat a écrit :
> 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.
>
I've always used sudo on Debian and I supposed it was the same on
all distros. Maybe naive...
So there is this secure_path, plus a list of allowed editors (for
visudo). Plus you can allow commands with absolute filenames, which
discards the use of PATH, plus you can allow commands only with given
arguments, and you can forbid commands with given arguments. That's a
lot of possibilities.
Now, if I don't secure the PATH and I allow users to run a command
of my own, which is itself insecure, because it allows the use of PATH,
then, sorry, I cannot accuse sudo!
Didier
::
Re: [DNG] automount, mount, and USB…
