Umask root?

[Paul T. Green]

I will be umasking multiple users in the next few days. Does root need to be umasked? With four sysadmins with access to root account, tto many world writable files exist out there I have to go and clean up. Do not want to have to face this in the future.

[A. Clay Stephenson]

I would set it to 027 as default. And let the convention be, if I want to make permissions less restrictive then I'll do it explicitly.

My 2 cents, Clay

[James R. Ferguson]

Hi Frank:

My preference is to provide a 'umask' of at least '022' or even '027' for root in its /.profile. I find it easier to "open-up" permissions later than to have to tighten them done after the fact.

...JRF...

[MANOJ SRIVASTAVA]

Hi Frank

I would leave it like that , even i case they are to write they can change it , your problem looks to be more of functional in nature.

Manoj Srivastava

[Bill Hassell]

If root's umask is zero, you have VERY SERIOUS security problems right now! Every file and directory that root has created is 666 or 777 respectively, unless root took the time to correct these permission errors. Such permission settings mean that anyone (not just root) can modify or remove root files and possibly worse, run a root script or program and obtain root privileges.

I would set umask as a MINIMUM to 022 right now in /etc/profile so all users have protection for their own files. root might be 022 but a more secure setting is 077 which prevents all users from accessing any file or directory until root makes a conscious decision to open up permissions.

To find all the errors, I would run the following commands to locate problems:

for DIRS in / /opt /usr /stand
do
find $DIRS -xdev -perm 777
done

Repeat the same commands but change 777 to 666 and run again. Then correct all the bad permissions.

[Bruce Regittko_1]

Hi,

Bill's right - change the umask setting as soon as possible in the /etc/profile file. You will also want to set the umask in the /etc/login file for your csh and tcsh shell users.

Also, keep in mind that users can override their default umask setting by issuing the command themselves so educate them on what it is and why it is what it is.

--Bruce

[Paul T. Green]

Bill, Bruce...
Tell me something (I do agree with both your comments), when I trust a system, I've been told that the default umask of "0" is changed to 07077, so nothing needs to be done to tighten up umask. I've been looking where this is set and cannot find it. Can you clear this up for me. Should I go and set the 022/077 umask on the /etc/profile anyway?

[Klaus Crusius]

/etc/profile is probably not the most secure place to spot the "umask 0xxx". The X sessions will not run through that automatically.

Better places: /sbin/rc, /sbin/rc.utils, ... .
and additionally /etc/profile, /etc/login for the login shells started from getty.

[Paul T. Green]

Klaus,
Where is the umask set when the server is trusted. I don't see it (can't find it).

[Bill Hassell]

Correct. In a standard system, umask is set (typically) in /etc/profile and /etc/login) for all users. However, if not set, umask defaults to 00 which means 777/666 direcory/file permissions respectively.

On an un-trusted system, by default login programs such as telnet and rlogin
set the umask to 00. On an un-trusted system, the umask is set in the login
script file. That file will be different depending on how you login. It is set
in the following places:

1. telnet = either ~/.profile or if that doesn't exist then /etc/profile

2. vue = either ~/.vueprofile or if that doesn't exist then /usr/vue/config/sys.vueprofile

3. cde = either ~/.dtprofile or if that
doesn't exist then /usr/dt/config/sys.dtprofile

You can set the umask for
login programs in the user login scripts(/etc/profile or /etc/login or .profile/.cshrc). Also you can set the umask per user in .dtprofile and .vueprofile for CDE and VUE

However, Trusted system design recognizes how critical this setting is to the system's health and set umask to 077, the most restrictive possible for non-owners/groups. I have not found where it is set though...probably in a program rather than a script. You can override the value but as mentioned before, good security means trust nobody until proven otherwise. Make a conscious decision to open up privileges.