Le 30/07/2015 11:28, Rainer Weikusat a écrit :
Didier Kryn <k...@in2p3.fr> writes:
Le 29/07/2015 16:35, a...@gulbrandsen.priv.no 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
