On Thu, 2008-03-27 at 17:53 -0600, Stephen John Smoogen wrote:
2008/3/27 Jeff Spaleta <jspaleta(a)gmail.com>:
>
>
> 2008/3/27 Jesse Keating <jkeating(a)redhat.com>:
>
> >
> >
> > Again, this argument is bunk. If they're not supposed to be ran by
> > normal users, hiding them behind a path is no form of security. One can
> > just run the full path to it. If they're not supposed to be ran by
> > users, they should have correct permissions on them, or they should
> > check EUID of the caller before doing anything.
> >
>
>
> The question is, do we have programs down the sbins that make the wrong
> assumption about path segregation equalling protection? And if so, how
> many? The obvious ones to me that need scrutiny are the executables that
> are setuid root. Do we need to take some extra care about those setuid'd
> executables?
>
Not that I have run into.. the main thing is you need to make the path
in the right order:
/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin.
Are you aware that that is not the same root's path, and the whole idea
was to take away the distinction of 'this program works like foo if I am
root, but bar if I'm a user'... And also, the 'su -' works and
'su'
doesn't problem. And the path with 'su -' is:
(some kerberos etc. garbage stripped out):
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
It seems like your suggestion at least has the following problems:
* /usr/local/[s]bin needs to come before anything
* the 's' variants should come before the non-s variants
* console-helper should be fixed if it's so broken as to require the
path order to be different for different classes of users to work
properly, or simply, have console-helper drop the /usr/sbin component
and move it to /usr/libexec which is the normal convention.
The first point is definitely true, the second two are only possible
true ;-)
David