Secure $PATH for regular user

Hi,

I remember, but can not find it, that for non root user it's advised
not include /sbin and /usr/sbin in $PATH. Is it right?

If yes, I'll be glad to find a reference to security audit indicating
it, as a proof to my manager :)

Thanks
Dmitry

On 29 Oct, 10:37, Dmitry <dim...@gmail.com> wrote:
> Hi,
>
> I remember, but can not find it, that for non root user it's advised
> not include /sbin and /usr/sbin in $PATH. Is it right?
>
> If yes, I'll be glad to find a reference to security audit indicating
> it, as a proof to my manager :)
>

I've never came across such a recommendation - all the programs I can
think of in these directories should have additional controls to
prevent non-root users abusing them, and may be needed to see the
state of the system (e.g. ifconfig, mount, fuser...). And your
recommendation sounds like Security by obscurity which is generally
considered a bad thing.

C.

On Mon, 2007-10-29 at 10:37 +0000, Dmitry wrote:
> Hi,
>
> I remember, but can not find it, that for non root user it's advised
> not include /sbin and /usr/sbin in $PATH. Is it right?
>
> If yes, I'll be glad to find a reference to security audit indicating
> it, as a proof to my manager :)
>
> Thanks
> Dmitry
>

Actually the converse is true. The root user should never inherit
the PATH of a normal user as that could lead to a compromise.

Do normal users NEED /sbin and /usr/sbin in their PATH? Normally, no.
However some tools, like ifconfig, can display useful information even
to a normal user and it's located in /usr/sbin.

On Mon, 29 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<1193654274.587361.265790@v3g2000hsg.googlegroups. com>, Dmitry wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>I remember, but can not find it, that for non root user it's advised
>not include /sbin and /usr/sbin in $PATH. Is it right?

It's not that it's not advised, it's more a tradition. This is a long
story - but generally, the stuff in /sbin and /usr/sbin are not
normally used/needed by the average user. Those few commands that a
user might need, such as 'arp', 'ifconfig', and 'route' can be accessed
using the full path to the command. Example:

[compton ~]$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/ibuprofin/bin
[compton ~]$ route -n
bash: route: command not found
[compton ~]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 189948 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 388 lo
0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 12673 eth0
[compton ~]$

>If yes, I'll be glad to find a reference to security audit indicating
>it, as a proof to my manager :)

I've no idea why there would be. Further, any auditor giving that kind
of advice is totally clueless and should be shot immediately. [1]

[compton ~]$ /sbin/route add -net 192.168.3.0 gateway 192.168.1.11
SIOCADDRT: Operation not permitted
[compton ~]$

Notice that while I can run the command to _GET_ information, I can NOT
run the command to _change_ anything. That's because any command that
is "sensitive" checks the UID of the person running the command, and
won't do "sensitive" or "critical" things unless the person is root.

Setting the PATH is a service of the shell, and the user can set the
PATH as they desire.

If letting your users see commands in /sbin/ or /usr/sbin/ is the
problem, you might change the permissions of that directory, but don't
be surprised if this causes other problems. You can also use a number
of shells in a restricted mode - that prevents users from changing
directories, or running any command with a '/' in it. Depending on
your situation, this may be your answer, or it may prevent your users
from doing useful work.

Finally, if you don't trust your users, why are they allowed on your
system in the first place?

Old guy

[1] A friend tells of a "security auditor" who demanded the 'administrator'
password on a Solaris system ("what account???") so that he could use his
floppy full of programs (on hardware that lacks a floppy drive), and who
told the friend not to worry because the floppy had been virus scanned.
The friend was nice enough to tell everyone he knew 1) the name of the
so-called "security auditor", 2) the name of the company the idiot
worked for, and 3) the name of the (now) ex-employee that hired these
idiots. Rote stupidity does not enhance security.

On 29 Oct, 10:37, Dmitry <dim...@gmail.com> wrote:
> Hi,
>
> I remember, but can not find it, that for non root user it's advised
> not include /sbin and /usr/sbin in $PATH. Is it right?
>
> If yes, I'll be glad to find a reference to security audit indicating
> it, as a proof to my manager :)

Under most Linux systems I've seen, there's a widget in /etc/profile
that *provides* /sbin and /usr/sbin for the root user, and does not do
so for non-root users. This is irritating if you use sudo to run
things as root, since programs from the sbin directories are not in
the PATH as expected.

Now, the "." and the "~/bin" directories, *those* do not belong in the
default PATH.

On Tue, 2007-10-30 at 06:17 -0700, Nico wrote:
> On 29 Oct, 10:37, Dmitry <dim...@gmail.com> wrote:
> > Hi,
> >
> > I remember, but can not find it, that for non root user it's advised
> > not include /sbin and /usr/sbin in $PATH. Is it right?
> >
> > If yes, I'll be glad to find a reference to security audit indicating
> > it, as a proof to my manager :)
>
> Under most Linux systems I've seen, there's a widget in /etc/profile
> that *provides* /sbin and /usr/sbin for the root user, and does not do
> so for non-root users. This is irritating if you use sudo to run
> things as root, since programs from the sbin directories are not in
> the PATH as expected.

The correct answer for those cases is to use the -i option (on newe
versions of sudo). The security risk is with sudo since it does leave
the PATH alone, which is exactly the huge security risk mentioned in my
other post in this thread. Again, has nothing to do with the what the
OP was asking...


>
> Now, the "." and the "~/bin" directories, *those* do not belong in the
> default PATH.
>

But sudo inherits the PATH of the current user invoking sudo. This is
VERY dangerous. Something to remember. e.g. Let's say your PATH is
PATH=/myuglynasty/bin:$PATH and inside that myuglynasty/bin directory
has fairly open permissions and a vicious copy of a common executable.
Hopefully you can see the problem.

On 2007-10-30, Nico <nkadel@gmail.com> wrote:
>
> Now, the "." and the "~/bin" directories, *those* do not belong in the
> default PATH.
>
I can understand "." but why "~/bin"?

On Tue, 30 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<1193750234.632859.264120@19g2000hsx.googlegroups. com>, Nico wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>Under most Linux systems I've seen, there's a widget in /etc/profile
>that *provides* /sbin and /usr/sbin for the root user, and does not
>do so for non-root users.

/etc/profile is a configuration file, and I've never noticed it being
standardized across distributions. /etc/profile is sourced when a
Bourne style shell is a "login" shell, but (with few exceptions such
as the new release of Mandriva) /etc/profile is not sourced in a GUI
login. In text based logins (that use /bin/login), the PATH is often
initially set by /bin/login, while a typical GUI sets the PATH in the
login manager:

[selene ~]# strings /bin/login | grep bin:
/usr/local/bin:/bin:/usr/bin
/sbin:/bin:/usr/sbin:/usr/bin
[selene ~]# strings /usr/X11R6/bin/xdm | grep bin:
/sbin:/usr/sbin:/bin:/usr/bin
/usr/local/bin:/bin:/usr/bin
[selene ~]#

The startup scripts for the login shell may then be used to replace
or alter the PATH (recall there are individuals who use a C shell
such as /bin/tcsh and friends - none of which know about /etc/profile).

>This is irritating if you use sudo to run things as root, since
>programs from the sbin directories are not in the PATH as expected.

Minor quibble - policy at every place I've seen sudo used was to
train the sudoers to ALWAYS run the commands with full PATHname,
even if the desired binary is in the users PATH. Admittedly, the
documentation that comes with sudo doesn't stress this elementary
precaution. Untrained users (the typical 'home' user) often don't
understand this - but then, they also lack a lot of basic security
concepts as well.

>Now, the "." and the "~/bin" directories, *those* do not belong in
>the default PATH.

The dot (".") in the PATH (or ending the PATH with a colon ":" which
has the same effect) I can agree should not be in the PATH. Why do
you feel that the individual user's home/bin directory should not be
in the PATH. What exploit are you assuming is possible due to this?
Most sane setups do not have that directory writable by other than
the owner, and placing nasties there requires the same elevated
permissions that are needed to replace system binaries in /bin/ or
similar. Hence, if they can screw up the users ~/bin, they can also
screw the entire system. What's the point?

Old guy

Moe Trin wrote:

> The dot (".") in the PATH (or ending the PATH with a colon ":" which
> has the same effect) I can agree should not be in the PATH. Why do
> you feel that the individual user's home/bin directory should not be
> in the PATH. What exploit are you assuming is possible due to this?
> Most sane setups do not have that directory writable by other than
> the owner, and placing nasties there requires the same elevated
> permissions that are needed to replace system binaries in /bin/ or
> permissions that are needed to replace system binaries in /bin/ or
> similar. Hence, if they can screw up the users ~/bin, they can also
> screw the entire system. What's the point?

huh system directories are owned and writeable only by root
directories in the home directory are writeable by the user of that
directory
meaning: in case of system dirs the euid has to be root to dump
malicious executables
in case of the home dir, the euid can be root or the owner (normal user).
this means a exploited program running as a normal user can dump an
executable
in that directory, if the attacker puts common unix executables in there
and if that dir is put in PATH
like this PATH="~/bin:$PATH". then you can be royally fucked, this is
especially true if your sudo is configured very pragamatically eg the
user is part of a group or can sudo anything without PASSWORD eg:
ALL=(ALL) NOPASSWD:ALL

now the attacker instead of actively trying to attack local running root
processes
or using exploits on executable SUID programs can just replace a common
tool like
iptables,lspci,ifconfig,kill,killall,... with a version that does the
same but also launch a reverse shell running as ROOT
now he can just go to bed and wait till the unknowing user uses sudo
(unknowingly ) on the malicious binary

yes this is dangerous !

goarilla wrote:
> Moe Trin wrote:
>
>> The dot (".") in the PATH (or ending the PATH with a colon ":" which
>> has the same effect) I can agree should not be in the PATH. Why do
>> you feel that the individual user's home/bin directory should not be
>> in the PATH. What exploit are you assuming is possible due to this?
>> Most sane setups do not have that directory writable by other than
>> the owner, and placing nasties there requires the same elevated
> > permissions that are needed to replace system binaries in /bin/ or
> > permissions that are needed to replace system binaries in /bin/ or
> > similar. Hence, if they can screw up the users ~/bin, they can also
> > screw the entire system. What's the point?
>
> huh system directories are owned and writeable only by root
> directories in the home directory are writeable by the user of that
> directory
> meaning: in case of system dirs the euid has to be root to dump
> malicious executables
> in case of the home dir, the euid can be root or the owner (normal user).
> this means a exploited program running as a normal user can dump an
> executable
> in that directory, if the attacker puts common unix executables in there
> and if that dir is put in PATH
> like this PATH="~/bin:$PATH". then you can be royally fucked, this is
> especially true if your sudo is configured very pragamatically eg the
> user is part of a group or can sudo anything without PASSWORD eg:
> ALL=(ALL) NOPASSWD:ALL
>
> now the attacker instead of actively trying to attack local running root
> processes
> or using exploits on executable SUID programs can just replace a common
> tool like
> iptables,lspci,ifconfig,kill,killall,... with a version that does the
> same but also launch a reverse shell running as ROOT
> now he can just go to bed and wait till the unknowing user uses sudo
> (unknowingly ) on the malicious binary
>
> yes this is dangerous !
>
>
>

my apologies for the incorrect quoting