World-writable permissions seem to resurface!

[Irwan Ismail]

Hi all,

What are the things that can cause world-writable permissions to resurface after they've been revoked? Our customer is having this problem and as such their audit by PwC always fails when it comes to this item. What can they do to ensure that it doesn't resurface again?

[Naveej.K.A]

Hi,

For any specific directory??

who is the owner for these directories??

check your umask in /etc/profile and the .profile in the owner of the directory for an incorrect umask.

a 022 umask should be fine and default

Regards,
Naveej

[Irwan Ismail]

Hi Naveej,

Thanks for the quick response! I've attached a couple of files from their servers. Please see if this helps to determine anything.

[Naveej.K.A]

Hi,

Most of the files are log files and not configuration files. Most of the files/directories have sticky bit set, so most of the files can not be deleted.

/dev/pts/* is supposed to have rw permissions, so that a user will be able to login/write to the terminal.

Regards,
Naveej

[Pete Randall]

If the auditors insist on something like this the best solution is to set up a cron job that changes the permissions to exactly what they want and set it up to run either every night or, at the very least, right before the auditors arrive.


Pete

[Naveej.K.A]

LOL!!!

Good solution Pete.

[Irwan Ismail]

Naveej,

I was just informed by the customer that the umask in /etc/profile is set to 037, which I believe is more restrictive?

Pete,

LOL! I'm sure that'll work and will address the auditor issue, but is there a better (common way) to solve this problem?

[Bill Hassell]

There's no easy way to fix this problem. As mentioned, some files/directories need world-writability (man pages for instance unless you don't want the ability to reformat the pages upon usage). Now there are several things that jump out as being seriously wrong:

/dev = 777 should NEVER have this permission. It must be 755.

/dev/vg00 = 777 probably has been that way since installation due to a lack of umask in the default HP-UX system. Change it to 755

/dev/rmt/ should be 600 so that users cannot write all over the critical backup tapes.

pwgr can be disabled if you have reasonable sized passwd files (a few hundred users or less). Just remove /var/spool/sockets/pwgr directory and the contents.

Some of the flagged items are 'blind' meaning that the auditor's tool is too dumb to exclude world-writable files and directories that are supposed to be in that state (ie, /dev/console /var/tmp /tmp, etc).

That takes care of most of the items. HOWEVER, if you've fixed these items before and they revert back again (especially the ones mentioned above like /dev) then change the root password immediately and every time a sysadmin calls to find out why root doesn't work, ask them about these changes. Also look in sulog and search through your sudo log (and syslog). (you do have sudo, right?) And of course search through .sh_history for root. Also check logins -d. If you see multiple UID=0, you should assume you've been hacked ('cause no sysadmin would ever allow duplicate root users--see comment about sudo)