On Thu, Jul 30, 2015 at 10:28:30AM +0100, Rainer Weikusat wrote: > 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.
So defining this secure_path means it's the PATH to be used for sudo? and if it's not defined it defaults to PATH? Is it the same for su? And where is this defined? -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
