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.