On Thu, Jul 30, 2015 at 10:28:30AM +0100, Rainer Weikusat wrote:
> 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.
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
::
Re: [DNG] automount, mount, and USB…
