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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
