Why does HP install with mode 777 files and default root umask of 00?

[Trever Furnish]

I just stepped into a position as admin of several existing HPUX11 boxes and noted that there are tons of world-writeable files on the systems. I just considered it an ordinary cleanup task for the future until today when I installed my first fresh HPUX 11.00 system and realized that a "clean" install has some 50 directories set to world-writeable.

I'm rather shocked - what's going on? Is this normal for HP? Am I doing something wrong during my install? Should I be setting the root umask more restrictive before I apply patches? Isn't it a bit silly for HP to ship a default configuration that has root creating files mode 777?

I'm checking modes like so:
find / -perm -o+w -type f >badfiles
find / -perm -o+w -type d >baddirs

On my newly installed system, that returns such surprising locations as (among many others):

/etc/SnmpAgent.d/snmpd.conf
/stand/build/mod_wk.d/krm/mod_conf.c
/opt/pred/var
/var/stm

I'm almost afraid to check for inappropriate sticky bits at this point, but that's next on the list.

In fairness I should mention that I did already install four patches, so if patches don't install with explicitely set file modes, then perhaps the problem is just that I should've set my umask as the first step upon booting into hpux. Is that the problem?

[Sanjay_6]

Hi Trever,

Even if the files have world write permissions, have you checked the write permission for thier parent directories.

Hope this helps.

Regds

[Craig Rants]

Trever,
You will always have a lot of world writeable files. I was looking at an audit we had done and 90% of it was a listing of our world writeable files. You definately don't have enough time to look at each file and determine if it should be world writeable or not, you also don't want to blanket change everything because some things will definately break. So this is a judgement area, it is really up to you, focus on areas of concern like your snmp and don't lose sleep about the others.

Just my opinion,
C

[James R. Ferguson]

Hi Trever:

You're not doing anything wrong. The permissions of software are set within the install scrips processed by 'swinstall'.

This is not quite as bad as first blush would suggest. You can improve things by setting the sticky bit on directories like /tmp and /var/tmp:

# chmod 1777 /tmp /var/tmp

In this case, all users can write to the directory but they can ONLY remove files for which they have explicit write permission.

You should also remove the write permissions from /usr/local.

As for a sensible 'umask', I use 027 for root in its .profile. You could certainly set at least a 022 umask in /etc/profile, too.

Regards!

...JRF...

[Darrell Allen]

Hi Trever,

This is not unique to HP. Other UNIX flavors do the same.

You should do some research on UNIX security, especially concerning building a bastion host. Search the forums for bastion and you'll get a lot of threads, one being http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x42b8cf38d6bdd5118ff10090279cd0f9,00.html

Darrell

[David Lodge]

I've often thrown my hands up at this - the most stupid one being /usr/local and below...

The best thing I can suggest is to run a script setting up proper permissions on directories...

Of course sometimes HP is really bad at this (eg the snmp configuration file and most of the ODE package!)

dave

[Trever Furnish]

Thanks for all the responses.

However, I don't think it's acceptable for *any* normal files or directories to be world-writeable. (By "normal" I mean to ignore those files and directories which must by world writeable by design, such as /tmp and special device files.)

Consider the situation where the unix system in question is serving actual login shells to thousands of students in a college setting. Is it acceptable to allow any user to fill the root filesystem or the /var filesystem? Why not just put the root password in /etc/issue.net?

My question wasn't really posed well, I guess - I didn't mean to ask whether it was good to have world-writable files, but rather whether what I was seeing was normal for HP or I had been negligent somewhere.

If I have time I'm going to re-do this system again and check the modes after a clean install *before* installing patches and see if setting the root umask correctly before installing the patches cleans things up a bit.

Thanks again for all the responses so far - any additional advice or info is certainly appreciated.

Sincerely,
Trever

[Christopher Caldwell]

I've always been critical of HP's loose permissions. Hopefully, if enough of us gripe, they'll do things differently.

You can change HP's default permissions - but the permissions will generally get changed back to default when you install patches or new revisions of software.

HP has some interesting built-in functionality to check/verify file permissions, directory permissions, files sizes, file modification times and file check sums; it's called swverify.

You get errors like
WARNING: Directory "/" should have group,gid "root,0" but the actual
group,gid is "sys,3".
or
ERROR: File "/usr/lbin/ups_mond" should have mtime "930845327" but
the actual mtime is "962922577".

Unfortunately, this information isn't infallible; in addition, sometime different products "argue" over what "correct permisssions are".



It would be nice if
1) the permissions, checksums, sizes, modification times, etc. were consitently applied and enforced across all products.
and
2) we could coerce things to use stricter permissions permanently by effectively telling SD-UX/IPD what permissions we want.
<\ehancement request>

[Bill Hassell · Accepted solution]

I don't think there is any formal reason why the permissions are unsafe. In my security talks, I recommend that you never put a new system into service until a security check is done. /usr/local used to be correct (755) but was changed to 777 at 10.00 and still remains 777.

Here's a quicky checklist:

> find /usr/local -type d -print -exec chmod {} \;
> Scan the following directories looking for 666 and 777 files:
> find / /opt /var /home /usr /stand -xdev -perm 777 -type d

> find / /opt /var /home /usr /stand -xdev -perm 777 -type f
> find / /opt /var /home /usr /stand -xdev -perm 666-type f

> Change *ALL* mountpoints in /etc/fstab to nosuid except /usr and /opt and /.

> Edit /etc/profile and add:
> umask 022

> Edit root's .profile to add:
> umask 077 # (or umask 027)

> Move root's $HOME from / to /root (this is to secure against fat-fingered root users--of which, none of us are a part)

> Edit /etc/mail/alaises and add:
> hostmaster: root
> webmaster: root
> postmaster: root

> then change root to forward to a 'real' sysadmin account that will always be read:
> root: sysadmin@mycompany.com

> Make sure that this statement is at the top of /etc/profile:
> trap "" 1 2 3

> and make sure this statement is at the end:
> trap 123

> Turn off all read, write and execute permissions for all disk and LVM device files (ie, 600)

> make sure (on newer servers) that the Guardian Service Processor (GSP) has a password.

> make sure the server has the remote support modem passworded and disabled. Use AirGap Security(tm) on the modem if you aren't using Predictive. (AirGap Security = pull out the phone line) 8-]

(changes to /etc/profile should also be translated into /etc/csh.login)

---

Therte are a lot more but the above needs to be applied to every HP-UX box regardless of revision. For a more in depth discussion of HP-UX security, get a copy of the brand new book: "HP-UX 11i Security" by Chris Wong (at any major online bokstore)

[harry d brown jr]

Take a look at these docs:

http://people.hp.se/stevesk/bastion11.html

live free or die
harry

[Wodisch]

Hello Trever,

I have just answered about another "hole" to Bill (McNamara)...
And the *winner* is: DCE-ACLs
Change permissions for your "host", "root", and all "depots" for the "swinstall/sw*" group of commands:

swacl -l root -M any_other: @ /
swacl -l host -M any_other:
swacl -l depot -M any_other: @ /var/spool/sw # and all your local depots

Since your "swagentd" runs as "root", everybody with proper DCE-ACLs can install and remove software on your stations (well, this must be turned on, before), but EVERYBODY on the whole planet (as far as the internet reaches) can read your IPD (Installed Product Database). All *they* need is access to your local DCE-RPC portmapper (ports TCP/135 and UDP/135) and the client ports (>1023).
Since Windows-systems do need that port, too, and 2000 seems NOT be able to restrict it (with what M$ calls IPsec), it might be free on your firewalls :-(

Just my ???0.02,
Wodisc