topic Re: umask in Operating System - HP-UX

umask

S.S. — Wed, 03 Feb 2010 01:13:55 GMT

Hi All,

As of the security reason, the auditors asked to change the umask of the following to 077.

• /etc/profile
• /etc/csh.login
• /etc/d.profile
• /etc/d.login
• /etc/default/security

If we change the umask to 077 (To prevent world readable, writable and executable file permissions) what will be the affect for the users in the operation?

May i know if i change the umask to 077, the already created files with umask of 022 can also changes to the permission 077 or else it will only affect the newly created files?

Can anyone suggest me it will be workout for the realtime operations.

Thanks!!

Re: umask

Kapil Jha — Wed, 03 Feb 2010 01:24:27 GMT

Auditor has asked to change umask of below files to 077 so as to make permission of these specified files to 700 (these are some security file)
Why you bothered about other file?
Other files should be having permission according to need.
Umask would set just the value so that any new file created would be having new values.
Old remains same.

BR,
Kapil+

Re: umask

Patrick Wallek — Wed, 03 Feb 2010 02:48:26 GMT

If the auditors are requesting "PERMISSION" changes on these files, then you need to understand what they do.

Here is a list of the files you mention from one of my 11.11 systems:

-r--r--r-- 1 bin bin 1974 Sep 1 2005 /etc/csh.login
lrwxrwxrwt 1 root sys 16 Aug 5 2003 /etc/d.login -> /etc/skel/.login
lrwxrwxrwt 1 root sys 18 Aug 5 2003 /etc/d.profile -> /etc/skel/.profile
-rw------- 1 root sys 105 Oct 4 2006 /etc/default/security
-r--r--r-- 1 bin bin 3106 Jul 19 2006 /etc/profile

Notice that /etc/profile and /etc/csh.login are readable by EVERYONE. They **MUST** be this way so users can read the files as part of the login process.

The /etc/default/security should be read/write by root, so securing that file is good.

The d.profile and d.login files are links, so permissions are basically moot.

If they are requesting a "UMASK" change for newly created files, that is a different story.

The 'umask' must be set in /etc/profile. Setting the umask ONLY AFFECTS newly created files and directories. It does NOT affect files already on the system.

If you have files and/or directories created with a umask of 022 you will have to change those manually.

You could do it with a find command, but you must really be careful about the files you change. You don't want to inadvertantly change an executable file that needs group/world read and execute.

Re: umask

Johnson Punniyalingam — Wed, 03 Feb 2010 03:01:13 GMT

Above mentioned file, You can change the file permissions as your auditor recommendations.

umask -> are configured under /etc/profile for globe under "root"

umake -> values can be set individual for specific user home directory .profile

man umask for more information

Re: umask

Michael Steele_2 — Wed, 03 Feb 2010 05:38:59 GMT

HI

Gee, I would push back on this and ask for a verifiable HP reference as there are thousands of O/S files.

What is the problem: You are putting the O/S into an unknown and uncertified by the manufacturer state if you start changing permissions around. In short, things might start f'ing up and/or stop working altogether.

O/S file permissions can be checked with the swverify check_permissions command. This command will compare current settings against patch or application distribution settings found in the SD-UX database.

From this report you can get an idea of how many world writeable files there actually are and then gage any chmod of these permissions.

You might corrupt the O/S if you're not careful and end up reloading the whole O/S.

PS Better have current Ignite and DATA backups before doing anything. Since DATA resides upon or uses the O/S configuration in every transaction, you may also be putting your DATA into an unknown / uncertified by the manufacturer state.

Re: umask

S.S. — Wed, 03 Feb 2010 07:48:13 GMT

Thank you all for your advice.

Re: umask

WayneHP — Wed, 03 Feb 2010 14:50:59 GMT

I would recommend you post this sort of question in the HP-UX/security FORUM.

This is standard security hardening but changeing UMASK in /etc/default/security can effect the way previous user processes and scripts interacted.

This often does not show up until months later.