Whonix 15.0.0.3.6 and also still the upcoming 15.0.0.3.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 / /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:
https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown
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:
https://manpages.debian.org/buster/libpam-modules/pam_exec.8.en.html
Unfortunately adduser does not support hooks yet.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019
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
umask
0026
Will fix.
The only thing that does not honor umask now is sulogin.
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.
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.
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).
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.
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.
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.
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 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?
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.
madaidan via Whonix Forum:
The bug will probably be fixed in
command-not-foundbefore 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.)
Ah, youâre right. The umask changes should probably be reverted then.
" 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.