group and world writeable files and dirs

[Theresa Patrie]

Hi,
I have been given the task of tightening security on our hpux workstations. Management came up with some scripts to check the status of my machines and they found many files/directories with world and group write permissions set. They insist that I remove world/group write permissions on everything unless I can justify the need. I have looked through the list of files/directories, but I have no idea if or where these permissions are required. Is there a standard list of files/directories that must be open to group/world? How can I figure out (other than trying it to see if it breaks anything) which files/dirs need to be open for world/group write?
Thanks,
Theresa

[RAC_1]

Yes. Group and user world writable files are a problem. Think about it. Any user can write to a file then.

you can find those files as follows.

find . -type f \( -perm 0002 -o -perm 0020 \) -print
find . -type d \( -perm 0002 -o -perm 0020 \) -print

Also world writable dirs should have their sticky bit set.

Anil

[Theresa Patrie]

Thanks Anil,
I already know which files/dirs are group/world writeable. My problem is figuring out which ones NEED to be open for world/group write. Temp areas are a good example, most of them need to be open for world write, but I do have the sticky bit set so only the owner can delete his own file. But there are many more dirs/files on my system that are open to world/group write. How do I know if they need to have these permissions or if I can shut of write permissions for world/group?

[Mel Burslan]

Theresa,

The question you are asking is age old and nobody was able to find an answer that is as clear as black and white.

First off, start with system related filesystems, i.e., /var, /usr/, /opt etc. As a sysadmin, you can tell if any file under these directories need a world and/or group write access. The answer, with the exception of temporary storage areas is no. Start tightening from that end.

Then it comes to the applications installed. If you leave it to the application owners, or code developers, they want everything wide open so that they can write sloppy code. In which case a hand-slapping is in order. My advice is to start tightening down from the executable directories. Also sit down on a short meeting with app owners and developers and discuss their needs for temporary file writes for the regular user processes, and only allow the areas they are writing to. At this point though, I should tell you you are entering an uncharted territory as no app developer/owner will be able to tell you where exactly they need open for writing. Your best bet is an adaptive control, i.e., tighten it a bit, listen for screaming people, if nothing is heard repeat the process.

As I have indicated, there is not black & white answer to your question.

Good luck.

[RAC_1]

The answer is it depends. Because we do not know what applications/program those files belong to. We do not how those apps/programs work and do the files/dir need to be open (world writable) that way.

Anil

[Bill Hassell · Accepted solution]

After some 20 years of HP-UX development, you can be fairly confident that HP has set the correct permissions on most everything. Now the new 11i v.2 does have install options that will tighten things up depending on the use of the machine, and HP also offers Bastille to aid in securing servers. Be very afraid of anyone that suggests improving security with something like:

chmod -R 700 /

(a new installation will be necessary) Same with suggestions that the setUID bit should be removed on everything. Security isn't just secure directories and files, it's a complete system state.

Make sure users are actually necessary on the system (alternate access methods), keep an eye on EVERY 777 and 666 permission you find. HP has now fixed /usr/local/bin directories, but these should always be 755. Same with /home. Only /tmp and /var/tmp should be 777, and other than /home, /tmp and /var/tmp, you shouldn't find any other 777 directories. Files that are 777 and 66 should always be scrutinized (they may be temporary but the creator needs some counseling on umask)

[Theresa Patrie]

Thanks for the replies.
Thanks Bill...my main concern are the system files. I am finding a lot of /var/spool, /var/opt, /var/stm, /var/news, /var/adm that are wide open. Actually, it looks like /var is my main problem. This is on an 11i system that I just installed so these are all the default permissions. I have to admit that I do not know what all these directories are used for and others I do. I do know what /var/spool is used for printing, but do the files need to be group/world writeable?? I could always try to make the change in /var/spool to see if printing breaks but some of the others, I am not sure. I've been told I am allowed to have some group/world write directories if I can justify it. Guess I have some research ahead of me and will not be able to complete this task yesterday as I was asked! Thanks to all for the input.

[Basheer_2]

Dear Patrie.
1) Download/Install HP's Free Product
security_patch_check

2) run it
/opt/sec_mgmt/spc/bin/security_patch_check -r >security.report

this will give you all the security violations. continue from there

[Keith Buck]

Several of these directories have been patched by HP (Security Patch Check will report the patches that you need). Most others are likely the result of having an open umask for users who created the directory.

/tmp and /var/tmp definitely need world-write permissions (that's what they are for), but in HP-UX 11i v2 the sticky bit has been added. Also in HP-UX 11i v2 a lot of the other world-write permissions have been removed on directories. However, note that a lot of testing was done and some product changes were made to ensure that this didn't break anything.

HP-UX Bastille will scan for world-writeable directories and create a script to tighten them down. However, the changes made by the resulting script are clearly marked as unsupported, and you have to manually edit the script to make it run. (remove the "exit" at the top of the script) Changing the permissions of these directories to something other than what HP shipped has not been tested and is not supported. If you find any directories that lead to a security defect, please report this through the normal security-alert@hp.com email address so that HP can address the issue.

As you allude to, catching breakages can be tricky. I've seen a situation where elm picks a temporary filename in /tmp based on pid of the process. If you set the sticky bit on the directory and elm crashes, the temporary file is left around until the pids recycle. At that point the user who is running elm under the same pid runs into a file collision and can't compose a mail message :( This is just one example of a defect that won't be found with normal testing, so you have to weigh risks on both sides.

Hope that helps.

-Keith

[Theresa Patrie]

Thanks for all the replies. Although there is not a simple answer, you have givem me a lot of good information.
Theresa