Secure $PATH for regular user

On 29 Oct, 10:37, Dmitry <dim... RemoveThis @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, 29 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<1193654274.587361.265790.RemoveThis@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....TakeThisOut@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....DeleteThis@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.DeleteThis@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.DeleteThis@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

I demand that goarilla may or may not have written...

[snip]
> my apologies for the incorrect quoting

You forgot about the bad formatting.

--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

stick: n. A boomerang that doesn't work.

Darren Salt wrote:
> I demand that goarilla may or may not have written...
>
> [snip]
>> my apologies for the incorrect quoting
>
> You forgot about the bad formatting.
>

On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4727ffb7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:

>Moe Trin wrote:

>> I should point out that the ending colon trick is not a POSIX feature.

>cool didn't know that

You should verify this on your system however.

>i only allow myself sudo access to the system tools i use most (about
>12) which happens to contain iptables ( i love verbose statistics )
>and just plain playing around with it.

If your /etc/sudoers file lists the specific commands you are allowed
use, then you are less vulnerable. Of course, if the attacker gets
access to the system and can use sudo to edit the /etc/sudoers file,
all bets are off. But as I said - it's a matter of degrees.

>some info:
>user@host:~ $ ls -l $(which su)
>-r-s--x--- 1 root wheel 31776 2006-08-22 22:08 /bin/su
>user@host:~ $ su
>root@host: $ sudo /bin/ls
>root is not in the sudoers file. This incident will be reported.

PLEASE TELL ME THAT YOU EDITED OUT THE PASSWORD LINES.

>> I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
>> the stupidity of having "." in the PATH (Practical Unix & Internet
>> Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
>> edition - see page 113 for the box "Stealing Superuser").
>
>can you recommend that book ?
>looking for some paper that can scratch my itch (unix+security)

Eric S. Raymond hasn't been recommending the book in his 'Reading List
HOWTO' since 2004 - feeling that it is dated, though the authors of the
Security-HOWTO still list it.

-rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO
-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO

Personally, I do recommend the book, although it is expensive (list
price US$55), but it's been around for a while so this also means you
may find it in a public or university library. The first edition (1991)
mainly covered UNIX security. It was completely re-written for the
second edition (ISBN 1-56592-146-8, April 1996, 971 pgs) and material
added about Internet security. The third edition (February 2003, 954
pgs) has more practical information added.

>> If the attacker knows you can sudo (or su) to root, they can use that
>> knowledge to obtain the authentication token (if there is one), and
>> then become root directly and screw the system without have to wait for
>> you to trip over their malware.

>still if this can mitigate even a small nr of attackers then it's a win

It would be more useful if the administrators actually learned something
about their systems in the first place. Many seem to want to install
everything on the CD/DVD without making any effort to find out what it
is, what it's used for, and whether or not it's going to be useful to
them or merely another unpatched security hole. The distributions are
partially to blame for this - playing the numbers game of "we have more
stuff than the other guys". They try to make the systems somewhat
self-maintaining (automatically checking for, and installing updates)
but some block this function under the impression that the software is
"calling home" with all kinds of secret/personal information.

In many operating systems (and that even includes windoze), there may
be unpatched security holes, but the FAR more common problem is user
stupidity. Uncrackable computers are already available. It's uncrackable
users that are in short supply

Social Engineering - Because there's no patch for human stupidity.

Old guy.

Moe Trin wrote:
> On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> <4727ffb7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:
>
>> Moe Trin wrote:
>
>>> I should point out that the ending colon trick is not a POSIX feature.
>
>> cool didn't know that
>
> You should verify this on your system however.
>
>> i only allow myself sudo access to the system tools i use most (about
>> 12) which happens to contain iptables ( i love verbose statistics )
>> and just plain playing around with it.
>
> If your /etc/sudoers file lists the specific commands you are allowed
> use, then you are less vulnerable. Of course, if the attacker gets
> access to the system and can use sudo to edit the /etc/sudoers file,
> all bets are off. But as I said - it's a matter of degrees.
>
>> some info:
>> user@host:~ $ ls -l $(which su)
>> -r-s--x--- 1 root wheel 31776 2006-08-22 22:08 /bin/su
>> user@host:~ $ su
>> root@host: $ sudo /bin/ls
>> root is not in the sudoers file. This incident will be reported.
>
> PLEASE TELL ME THAT YOU EDITED OUT THE PASSWORD LINES.
>

Offcorse

>>> I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
>>> the stupidity of having "." in the PATH (Practical Unix & Internet
>>> Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
>>> edition - see page 113 for the box "Stealing Superuser").
>> can you recommend that book ?
>> looking for some paper that can scratch my itch (unix+security)
>
> Eric S. Raymond hasn't been recommending the book in his 'Reading List
> HOWTO' since 2004 - feeling that it is dated, though the authors of the
> Security-HOWTO still list it.
>
> -rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO
> -rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
>
> Personally, I do recommend the book, although it is expensive (list
> price US$55), but it's been around for a while so this also means you
> may find it in a public or university library. The first edition (1991)
> mainly covered UNIX security. It was completely re-written for the
> second edition (ISBN 1-56592-146-8, April 1996, 971 pgs) and material
> added about Internet security. The third edition (February 2003, 954
> pgs) has more practical information added.
>
>>> If the attacker knows you can sudo (or su) to root, they can use that
>>> knowledge to obtain the authentication token (if there is one), and
>>> then become root directly and screw the system without have to wait for
>>> you to trip over their malware.
>

what do you mean with authentication token ?

>> still if this can mitigate even a small nr of attackers then it's a win
>
> It would be more useful if the administrators actually learned something
> about their systems in the first place. Many seem to want to install
> everything on the CD/DVD without making any effort to find out what it
> is, what it's used for, and whether or not it's going to be useful to
> them or merely another unpatched security hole. The distributions are
> partially to blame for this - playing the numbers game of "we have more
> stuff than the other guys". They try to make the systems somewhat
> self-maintaining (automatically checking for, and installing updates)
> but some block this function under the impression that the software is
> "calling home" with all kinds of secret/personal information.
>

thats why i use slackware, freebsd

> In many operating systems (and that even includes windoze), there may
> be unpatched security holes, but the FAR more common problem is user
> stupidity. Uncrackable computers are already available. It's uncrackable
> users that are in short supply
>

talking about openvms, tandem ?

> Social Engineering - Because there's no patch for human stupidity.
>
> Old guy.

On 30 Oct, 18:00, Chris Cox <ccox_nopenot....TakeThisOut@airmail.net> wrote:
> On Tue, 2007-10-30 at 06:17 -0700, Nico wrote:
> > On 29 Oct, 10:37, Dmitry <dim....TakeThisOut@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.

No, because default users in these Linux systems do not get /usr/sbin
or /sbin in their path! It's filtered out in the /etc/profile, so you
do not in fact get the default PATH for the root user because neither
the "sudo -H" nor the "sudi -i" re-source the /etc/profile file where /
sbin and /usr/sbin get added, when your UID is 0 as for the root user.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

,--- Dmitry writes:
| 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?

I'm also not sure about thether it is some kind of recommendation, but
authentication mechanisms of couple of Linux distros (at least Redhat
based) relies on this assumption.

- ----8<----8<----
wahjava [~] chatteau $ ls -l /usr/bin/system-config-network
lrwxrwxrwx 1 root root 13 2007-09-10 12:31 /usr/bin/system-config-network -> consolehelper
wahjava [~] chatteau $ ls -l /usr/sbin/system-config-network
- -rwxr-xr-x 1 root root 188 2007-09-06 13:35 /usr/sbin/system-config-network
- ---->8---->8-----

e.g. in above case when unprivileged user executes
'system-config-network' (with no /sbin:/usr/sbin in PATH),
'/usr/bin/consolehelper' gets started and does the authentication work
and if user is authenticated successfully, starts the actual
executable, which in above case present in '/usr/sbin'. So in such

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

| Thanks
| Dmitry

HTH
- --
Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHM2utHy+EEHYuXnQRArwsAJ40l6UjRtoSrJo23le+F6iWGzCWbACeN+Jk
W0RWzWU5W9DQH2vJYjAJa6Y=
=nOBI
-----END PGP SIGNATURE-----

On Fri, 09 Nov 2007, in the Usenet newsgroup comp.os.linux.security, in article
<m34pfw7bdf.fsf RemoveThis @chatteau.d.lf>, Ashish Shukla
=?utf-8?B?4KSG4KS24KWA4KS3IOCktg==?= =?utf-8?B?4KWB4KSV4KWN4KSy?= wrote:

>--- Dmitry writes:

>| 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?
>
>I'm also not sure about thether it is some kind of recommendation, but
>authentication mechanisms of couple of Linux distros (at least Redhat
>based) relies on this assumption.

I certainly would not call that 'authentication'.

> ----8<----8<----
>wahjava [~] chatteau $ ls -l /usr/bin/system-config-network
>lrwxrwxrwx 1 root root 13 2007-09-10 12:31 /usr/bin/system-config-network
-> consolehelper
>wahjava [~] chatteau $ ls -l /usr/sbin/system-config-network
>-rwxr-xr-x 1 root root 188 2007-09-06 13:35 /usr/sbin/system-config-network
>---->8---->8-----
>
>e.g. in above case when unprivileged user executes
>'system-config-network' (with no /sbin:/usr/sbin in PATH),
>'/usr/bin/consolehelper' gets started and does the authentication work
>and if user is authenticated successfully, starts the actual
>executable, which in above case present in '/usr/sbin'. So in such

....? Have no idea what you were going to say there.

You might have a look at the PATH for the user, and for root. You will
see that root has the same basic directories in his PATH, but that
the 'sbin' directories come before the 'bin' directories. Otherwise,
the so-called "consolehelper" application would be hit by root trying
to use the other so-called helper programs like 'system-config-*'.
Recall that the shell will use (excluding built-ins) the first
usable instance of a command found in the PATH. 'consolehelper'
was developed to allow more limited access to privileged commands
by ordinary users in an effort to reduce the number of newbies
using the privileged account for ordinary use as they do in windoze
because they feel they need the extra privilege for some reason.

The 'system-config-*' (originally called 'redhat-config-*' and renamed
in Fedora Core 2) are replacements for the earlier (RH5.1) 'linuxconf'
helper that Red Hat selected as the tool to help inexperienced system
administrators. These helpers tend to be proprietary, and limited to
a distribution (and it's clones if any). Other distributions use other
tools - 'sudo' being yet another mechanism, and even the GUI desktops
are getting into the act with their own "tools". Another disadvantage
of these helpers is that they tend to hide what they are actually doing,
and when the tool is missing, or won't work, the inexperienced admin
is left without recourse.

Old guy