change default umask

Currently still:

sudo -u man bash
umask

0026

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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916783

It is probably due to our umask lockdown.

Workaround:

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.

Examples:

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).

2 Likes
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.

mktemp

/tmp/tmp.ol7zDa3XgC

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.

Yes.

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

Ah, you’re right. The umask changes should probably be reverted then.

1 Like
1 Like
1 Like

" 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"

This worked for me, at least on my primary vm. Still not sure why my VM clones don’t recognize /etc/apt/sources

Umask hardening was undone and replaced by permission-hardening.

Useful for places outside the /home folder such as for example /tmp.