Change default umask.

Given our current implementation, still useful to set umask using sudo too?

This is what Qubes is using:

sudo cat /etc/sudoers.d/umask

# Sudo's defualt umask is 077 so set sane default of 022
Defaults umask = 0002
Defaults umask_override
1 Like

Sounds good. I don’t see any reason why this would be a bad thing.

Not sure. I never knew sudo could configure a umask. It might set the correct umask for sudo -u man bash and sudo sulogin so it may be useful.

1 Like

madaidan via Whonix Forum:

Sounds good. I don’t see any reason why this would be a bad thing.

There might be some systems using a webserver or something and then
pointing these to files in user home or so. An upgrade would break their
setup for them. Not a good enough reason to not do this since easily
fixed. A Whonix News warning about this could suffice.

1 Like
1 Like
1 Like

Whonix and also still the upcoming still have /home/user accessible by other non-root users. That is for files copied over from /etc/skel during creation of the /home/user folder. umask changes are functional so new files are hidden. This is because during build security-misc gets installed before user user gets created. Not too bad but this can be fixed. Solution…

Removes read, write and execute access for others for all users who have home folders under folder /home by running for example “chmod o-rwx /home/user” during package installation, upgrade or pam. This will be done only once per folder in folder /home so users who wish to relax file permissions are free to do so. This is to protect previously created files in user home folder which were previously created with lax file permissions prior installation of this package.

This could use security review.

File https://github.com/Whonix/security-misc/blob/master/usr/share/pam-configs/permission-lockdown-security-misc effective results in files /etc/pam.d/common-session / /etc/pam.d/common-session-noninteractive adding after:

session required pam_unix.so

A new following line:

session optional pam_exec.so debug seteuid /usr/lib/security-misc/permission-lockdown

Actual implementation is here:

Security discussion: I had in mind if using malicious user names in /home leading to root code execution by users, but this isn’t possible because to create a malicious user name, root access is required in the first place. And one who has root access, does not bother exploiting /usr/lib/security-misc/permission-lockdown. Also pam sets sane environment variables which are not in reach by non-root users at that stage. Not using set -e or so because this script failing shouldn’t block login.

See also:

Unfortunately adduser does not support hooks yet.
Therefore using pam_exec to make sure home folder gets right permissions before user login.
Postinst isn’t a reliable way to enable this either since the installation time of the security-misc package isn’t fixed during build of VM images. User “user” may or may not be created by the time of the installation of the security-misc package.


Currently still:

sudo -u man bash


Will fix.

1 Like

The only thing that does not honor umask now is sulogin.

1 Like

Run into exactly this issue with command-not-found:

It is probably due to our umask lockdown.


sudo chmod o+r /var/lib/command-not-found/commands.db*

I am considering to apply that workaround by default, not great, but if this is the only of a very few issues due to umask changes this is ok.

1 Like

Another umask related issue also with command-not-found.

It does not just require sudo touch /etc/apt/sources.list but also sudo chmod o+r /etc/apt/sources.list due to our umask hardening. I hope we won’t run into many such issues.

1 Like

Debian default umask.

umask 022
touch uuu

ls -la uuu
-rw-r–r-- 1 user user 0 Aug 17 09:22 uuu

Currently security.misc changes to 006.

umask 0006
touch abc

ls -la abc
-rw-rw---- 1 user user 0 Aug 17 09:23 abc

While we harden, while we remove others from reading files, we also relax permissions. We allow group members to write to files where they previously did not have write access. This looked ok due to UPG.

However, upon reflection, since we change this system wide, this may be a bad idea.

Some folders/files created by the system/packages are created with a different group. I.e. owner might be root but group might be shadow, pip or otherwise.


ls -la /etc/cups/subscriptions.conf

-rw-r----- 1 root lp 93 Jul 19 09:40 /etc/cups/subscriptions.conf

sudo ls -la /etc/ssl/private/ssl-cert-snakeoil.key

-rw-r----- 1 root ssl-cert 1704 Mar 27 2018 /etc/ssl/private/ssl-cert-snakeoil.key

Therefore our hardening attempts might result in actually relaxing write access for group when the group is different than the owner. Debian packages might keep care of the required umask but there might also be bugs.

Similar bugs (which were about too much hardened rather than too relaxed permissions) reported above (command-not-found).

Therefore I am planning on changing default umask yet again.

umask 027
touch test2
ls -al test2

-rw-r----- 1 user user 0 Aug 17 09:26 test2

Thereby we would harden permissions, i.e. others cannot read files but we also don’t relax any permissions (as previously allow group to write).

1 Like
1 Like

I don’t think this is something that should be fixed on Whonix’s end. Debian packages should always set the correct file permissions with chmod or something similar. Relying on the system umask is very unreliable.

I don’t think that is umask related. Whonix never shipped /etc/apt/sources.list before so getting this error just because of a change in file permissions for a non-existent file is weird and doesn’t seem right.

This is probably something else.

Sounds good.

1 Like

Setting the umask in /etc/profile might fix that.

Try creating /etc/profile.d/umask.sh and adding umask 027.

Setting the umask via the bashrc may also work. Edit /etc/bash.bashrc and add umask 027.

1 Like

So what do you suggest? Leave command-not-found broken in next stable Whonix release?

They should indeed. This is a bug in command-not-found. However, umask changes by security-misc / Whonix will trigger this bug.

This command-not-found bug already has a patch attached https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916783 not yet reviewed by command-not-found Debian maintainers.

So it’s also a Whonix issue meanwhile. Three options

A) leave command-not-found broken by default
B) apply the workaround by default
C) undo umask changes
D) manually apply the command-not-found patch

This also is a bug in command-not-found. It shouldn’t throw such a warning just because is unavailable.

The security-misc / Whonix related impact here that the workaround which would on before security-misc / Whonix made umask changes would be

sudo touch /etc/apt/sources.list

After the umask changes the workaround would be

sudo touch /etc/apt/sources.list
sudo chmod o+r /etc/apt/sources.list

This is a usability issue. Will elaborate.

1 Like

That was already “fixed” with my next post where I linked this this commit:

Atm there is no need for /etc/profile.d. umask is as of security-misc current state perfectly consistent everywhere the same.

I am writing “fixed” in quotes since while umask now has expected values, this is creating issues. Will elaborate.

1 Like

Now tb-starter package has this issue:

bash -n /etc/torbrowser.d/50_user.conf
bash: /etc/torbrowser.d/50_user.conf: Permission denied

It was reported by a tester here:

So config files created by root (in /etc dunno if this matters elsewhere too) are now no longer readable by others. This leads to an usability issue as above and might potentially lead to similar issues.

Another issue is sudo make install (by genmkfile) - also leading to permission denied errors since using sudo would install to /usr/bin etc copy with umask unreadable by user user.

Therefore I am considering to remove umask changes. We now have user home folder permission lockdown by security-misc package which effectively does this:

chmod o-rwx /home/user

That should protect 80-90% of the user’s files from other compromised non-root users anyhow? So if we revert to Debian default -rw-r--r-- (umask 0022) it does not matter. Compromised non-root users still cannot read files by user user in folder /home/user.

What other folders do you expect users create files in where Debian default -rw-r--r-- (umask 0022) would cause issues?

/tmp? Should not be an issue. Applications should be using mktemp (or appropriate similar API). And there it’s not an issue.



ls -la /tmp/tmp.ol7zDa3XgC

-rw------- 1 user user 0 Aug 17 20:40 /tmp/tmp.ol7zDa3XgC

Any other cases where Debian default -rw-r--r-- (umask 0022) is as much of an issue to justify the breakage we are already having and potential further issues?

1 Like

The bug will probably be fixed in command-not-found before the umask changes are in the next stable Whonix release. If not, the workaround should be applied.

This can be fixed by only applying the umask changes for non-root users. We can create a profile.d script that checks if the UID is not 0 then applies the new umask. This way, any files created by the root user will still be readable by others which should prevent any configuration files from being messed up.

There likely won’t be many sensitive files created by the root user that isn’t intended to be readable by others anyway.

No, any newly created file will still be readable by other users. Only the files already in the home folder will be protected. The permission lockdown only runs once so it won’t protect any files created after it has run.

Mainly newly created files in the home folder.

1 Like

madaidan via Whonix Forum:

The bug will probably be fixed in command-not-found before the umask changes are in the next stable Whonix release.

Unlikely since Whonix now releases more frequently. (Search term:
rolling release.) These changes will make their way into next stable
Whonix release sooner or later. Could be in 1 to 4 weeks.

If not, the workaround should be applied.


There likely won’t be many sensitive files created by the root user that isn’t intended to be readable by others anyway.

ssh keys, ssh authorized_keys, ssl keys, /etc/shadow but these are
probably already handled by the system in read permission restricted
for others ways anyhow so hopefully don’t matter.

No, any newly created file will still be readable by other users. Only the files already in the home folder will be protected. The permission lockdown only runs once so it won’t protect any files created after it has run.

No. If the root folder forbids read access, any folder after that
“barrier” will also be inaccessible even though having more relaxed
permissions. Example:

touch /home/user/a
chmod o+r /home/user/a
sudo -u man cat /home/user/a

cat: /home/user/a: Permission denied

The permission lockdown keeps out any non-root out of /home/user.

(Unless root would run sudo chmod o+r /home/user or addgroup or
similar but if they do so, they should be free to do so.)

Please run sudo chmod o-rwx /home/user and then try to make any file
accessible in /home/user by non-root users other than user. (Without
again using chmod directly on /home/user.)

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]