List of required SUID/SGID/World-writable Files in HP-UX

[EdTMC]

Hi All,

Is there any official list of required SUID/SGID/World-writable files for HP-UX?

Noticed that there are quite a number of these files in the system but is concern whether removing these permissions will break the system.

Thx for any advice given.

[Court Campbell]

definitely leave /usr/bin/passwd alone.

[Peter Nikitka]

Hi,

to check a single file, if it belongs to a package installed by HP-SW-disributer, use
swlist -l file | fgrep filename

or for multiple use:
swlist -l file >/tmp/allfiles-from-swdist
fgrep filename /tmp/allfiles-from-swdist

You can create a script, checks all reported files against this list.

mfG Peter

[Robert Fritz]

Hi there,

The quickest way to determine if the file permissions on an HP-UX system have been altered is with swverify.

If you run swverify \*

and then run the associated swjob, you'll get a list of all the changes to non-volatile files on the system (including permission/SUID changes) that were shipped in SD packages (which includes just about all HP-UX software, and many 3rd-parties).

In general I'd only remove SUID bits from software that you're sure you don't use... though in many of *those* cases, removing the corresponding software package is cleaner.

Removing SUID bits can introduce subtle breakage within the system so should always be done very cautiously.

[Dennis Handly]

Any reason you mentioned "World-writable Files"? There should be none.

[Olivier Masse · Accepted solution]

World-writable directories: Mandatory for /tmp and /var/tmp, but with the sticky bit set so that users can't delete each other's files. As for world-writable files, nothing comes to my mind right now.

Suid: As someone already said, only passwd absolutely needs to remain suid. DON'T wrap it with sudo/privrun!! Everything else is fair game, but your users could loose a lot of useful commands such as glance.

Sgid: Normally I don't consider these files and directories as security threats, as long no top-level directory (such as /opt for example) has an sgid bit.

If you're interested, I wrote a scanner a few years ago that identifies all your suid/sgid/world-writable files which you can use to perform regular audits, it's available here:
http://www.mayoxide.com/ncops/

Bye

[Bill Hassell]

If you have a standard HP-UX installation, then all the current settings are correct and safe -- they have been evaluated over the last 20 years and are correct except for /usr/local directories (depending on your version of HP-UX). swverify will report any changes from the original install. SUID/SGID programs are 100% required and changing them will definitely break some part of your system. Do not try to 'improve' the HP-UX portion of your system by disabling SUID and/or SGID bits.

You can get a complete list of the permissions, owner, and group by running swlist like this:

swlist -a mode -a owner -a group -l file

Now /home is not covered in the base HP-UX system except for the directory which should be 755. Here are some useful improvements:

1. find /usr/local -type d -exec chmod 755 {} +

2. chmod 1777 /tmp /var/tmp

3. add nosuid to /tmp /var /home

#1 fixes the default 777 permissions that have been there for more than a decade. /usr/local is very commonly used for add-on programs and should be protected on production machines. #2 prevents non-owners of files from removing them. Without the 1000 bit set, anyone can remove every file in these directories. #3 prevents SUID/SGID scripts and programs from running from these directories. Note that 11.31 has more extensive controls for SUID/SGID programs and/or scripts.

Now there is a set of world-writable directories and files: the man pages. It is your choice to allow these directories to remain world-writable. If you turn off the world write bits, then every man page will report the "reformatting...please wait" message...not a big deal.

Now for applications that have been added to the system, this gets complicated. Some application authors are clueless about proper permissions and may override your authority to store things in the proper place. And they may have created programs or scripts that have SUID/SGID bits set. The only fix is to get a list of all the files and directories (and their permissions and ownerships) that will be created after the install is complete.

[EdTMC]

Thx for all the useful information :)