This was implemented but could be disabled if there is a good argument against it.
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
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.
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.
Whonix 184.108.40.206.6 and also still the upcoming 220.127.116.11.9 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-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.
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.
sudo -u man bash umask
The only thing that does not honor umask now is
Run into exactly this issue with
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.
Another umask related issue also with
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.
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
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 (
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).
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.
Setting the umask in /etc/profile might fix that.
Try creating /etc/profile.d/umask.sh and adding
Setting the umask via the bashrc may also work. Edit /etc/bash.bashrc and add
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.
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.
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.
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
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
0022) it does not matter. Compromised non-root users still cannot read files by user
user in folder
What other folders do you expect users create files in where Debian default
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
0022) is as much of an issue to justify the breakage we are already having and potential further issues?
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.