Root PATH shares writable path with users

[TheJuiceman]

I need to clean up our PATH settings. We currently have a path set in /etc/profile that is writable by users.

Root's PATH is set as
PATH=/usr/sbin:/sbin:/root:$PATH

I would like to clean up root's PATH so that this security problem is fixed. However, I am worried by removing "$PATH" from root's profile will cause software/programming problems (and I would prefer not to have to copy everything into root's profile and then have to remember to edit it every time a program change is made)

The options I am seeing are:

1. Edit root's PATH to exclude $PATH, include what is needed from /etc/PATH, and try to keep it up-to-date
2. Edit each users' PATH and remove the questionable path from /etc/profile (the questionable path is set in /etc/profile, not /etc/PATH). Obviously a long and painful process.

In either case, it looks like I would need to take it out of /etc/profile and either put it in each user's .profile or in /etc/PATH.

I'm sure there is a better way to go. Any ideas? Thanks

[Torsten.]

>> We currently have a path set in /etc/profile that is writable by users.



Can you explain this?

[James R. Ferguson]

Hi:

The standard root '.profile' declares :

# PATH=/usr/sbin:$PATH:/sbin:/root

...which, in part, is based on what '/etc/profile' builds using '/etc/PATH'. Since '/etc/PATH' should only be *readable* the problem of security shouldn't exist.

If you mean that '/etc/profile' is writable by any user, then yes, you have a security hole.

Regards!

...JRF...

[Patrick Wallek]

What I would do:

Clean up /etc/PATH so that it only has what is absolutely required for all users.

Set up whatever you need for root in roots .profile file.

If particular users needs something other than the normal path, set that up in their own .profile.

[TheJuiceman]

/etc/PATH and /etc/profile both have the proper permission on the files themselves. There is a path INSIDE /etc/profile that is writable to users.

Inside /etc/profile, we have such...

export PATH=$PATH:/misc/writablepath:/usr/local/bin

Root should not need access to the /misc/writablepath and, what I understand, should not have /usr/local/bin in its PATH either.

[James R. Ferguson]

Hi (again):

> Root should not need access to the /misc/writablepath and, what I understand, should not have /usr/local/bin in its PATH either.

Then you need to clean-up '/etc/profile' to eliminate this world-writeable directory. Modify the *users* '.profile' as necessary to add the required directory to their PATH in *their* profile.

You are correct, '/usr/local/bin' should not be present in 'root's PATH either, but this directory should only be executable by non-root users so you the administrator control its contents.

Regards!

...JRF...

[TheJuiceman]

Blah....I was hoping not to have to edit thousand of users .profiles :(

[Steven Schweda]

> Blah....I was hoping not to have to edit
> thousand of users .profiles :(

But if "/etc/profile" is a script, and if
(some variant of) "whoami" works, then why
couldn't it do different things for different
users?

Why couldn't it do permission checks on a
directory before adding it to PATH (for some
particular user(s))?

As usual, many things are possible.

[Bill Hassell · Accepted solution]

I wrote the attached script to point out exactly what the poster is referring to. This script starts by verifying /etc/PATH, the system-wide starting point for setting the PATH variable. It will show these vulnerabilities:

# - world-writable paths
# - duplicate paths
# - non-existant paths or paths that are not directories
# - paths that are symlinks
# - : at end of $PATH, :.: or :: in PATH

A world writable path is /tmp for example. NEVER have a world-writable path included in $PATH for any user. Doing so allows Trojan and other rogue scripts to be accidentally run.

NOTE: HP supplies a lot of useless paths in the default /etc/PATH. Many refer to non-existent software packages and tools. A good sysadmin puts only the paths needed by ordinary users in /etc/PATH.

Then in /etc/profile (I'm assuming no scummy csh users are on the system) the PATH value is established for root separately from ordinary users. For instance, /usr/sbin and /usr/lbin should only be in root's PATH. Similarly, specialized applications like Sybase and Oracle, etc need additional environment changes but these should not be global for every user. root probably needs slightly different database paths than a normal user.

Once /etc/PATH has been checked by scan-path, then the current $PATH variable is checked.

A very long PATH is a big security risk -- keep it short for everyone. Users can add their own paths to $PATH as needed in $HOME/.profile

And good scripts NEVER use the current value of $PATH. Always start a script with:

export PATH=/usr/bin

and then add on as required by the script.

[Dennis Handly]

>Bill: NOTE: HP supplies a lot of useless paths in the default /etc/PATH. Many refer to non-existent software packages and tools.

If things are working correctly, if you install a product, it gets added and when you remove the product, it gets removed from /etc/PATH.

[Bill Hassell]

> Dennis: If things are working correctly, if you install a product, it gets added and when you remove the product, it gets removed from /etc/PATH.

I probably should have worded it differently -- out of the box there are a number of installed products that may never be used, and their paths are in /etc/PATH. For the majority of HP packaged products, removing the package also removes the entry from /etc/PATH.

[Horia Chirculescu]

Hello,

>I would like to clean up root's PATH so that this security problem is fixed

where is the 'security problem'? What is to fix here? You are talking about root's account. Do you believe anything you will do on your $PATH variable will improve security on your system?




>/etc/PATH and /etc/profile both have the proper permission on the files themselves. There is a path INSIDE /etc/profile that is writable to users.

>Inside /etc/profile, we have such...

export PATH=$PATH:/misc/writablepath:/usr/local/bin

>Root should not need access to the /misc/writablepath and, what I understand, should not have /usr/local/bin in its PATH either.

Do you believe that modifying the $PATH variable would keep root to access (as you say above) any executable from /misc/writablepath ?

Who told you that root should not have /usr/local/bin in its $PATH variable?

There are a lot of programs (compiled from source for example) that are installing by default in /usr/local


Horia.

[Bill Hassell]

> where is the 'security problem'? What is to fix here? You are talking about root's account. Do you believe anything you will do on your $PATH variable will improve security on your system?

Where is your passwd program located? If you (as root) do NOT use a full path (/usr/bin/passwd) then you have no idea what will be executed. Some novice sysadmin decided to add /tmp to /etc/PATH at the beginning of the list and now the hacker's passwd script in /tmp is going to capture everyone's passwd (as in: PATH=/tmp:$PATH) /tmp is world writable and ANYONE can create scripts or programs that mimic HP-UX commands.

Unless you use a full path or use the whence or type command before using a particular program, you will have a very serious security risk.

In the above example with /tmp:

$ PATH=/tmp:$PATH
$ echo "echo 'I fooled you!'" > /tmp/passwd
$ chmod 755 /tmp/passwd
$ passwd
I fooled you!

$ type passwd
passwd is /tmp/passwd
$ which passwd
/tmp/passwd

A hacker (actually, anyone) can simply store a script called su and passwd in /tmp and with $PATH compromised, your system is no longer secure.

[Dennis Handly]

>Bill: A hacker can simply store a script called su and passwd in /tmp and with $PATH compromised, your system is no longer secure.

If you want to keep running to keep ahead of them, you can set the sticky bit in /tmp and then touch empty files that aren't executable for each script you might execute by mistake.
(Much easier to leave out /tmp.)

[Horia Chirculescu]

Hello,

>Inside /etc/profile, we have such...

>export PATH=$PATH:/misc/writablepath:/usr/local/bin

Here writable directory is set after $PATH (/etc/PATH).


Keeping /tmp clean is a security task completely different than messing around ( willingly ) with $PATH variable.

>Some novice sysadmin decided to add /tmp to /etc/PATH at the beginning of the list

If the sysadmin makes this setup (add /tmp or other world-writable directory first in the list) , I assume that he would know what he is doing (maybe setting up a honey pot).


The only security problem related to $PATH variable could be the size of it (as a string) which could conduct in some rare occasions to buffer overflow on some buggy applications mostly custom developed.

Horia.

[TheJuiceman]

Thank you to all that responded. By what I'm seeing, it still looks like my original premise was the only way out.....blah