Closed monsieuremre closed 19 hours ago
Needs at minimum this: https://github.com/Kicksecure/security-misc/blob/master/debian/security-misc.links ?
This needs some test cases for the different environments. Could you please create a list of different environments (mentions in https://github.com/Kicksecure/security-misc/issues/185), add to https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation and test what you can?
Could you please create a list of different environments (mentions in https://github.com/Kicksecure/security-misc/issues/185), add to https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation and test what you can?
What do you mean? We can also set the umask for ssh too, if we want some different value there. But I don't get what is meant by different environments.
What do you mean?
Oh ok. Su sudo and manual execution of root privileged commands are covered with the exemption. So they will use the weak umask. Logins are also covered obviously. SSH logins are not covered, but that can be set separately as I said.
When it comes to X11 and Wayland login, I have no idea. If these run as services or daemons, then they are not exempted. But here we can use systemd drop in files if necessary. But I don't see any downsides to these things having strong umasks.
Qubes dom0 sudo xl console vmname - no idea. Qubes is very different, cannot know without testing.
I need a checklist before this can proceed further. (No need to run all tests by yourself.)
One would be created by me one day but that could take time. Faster if contributed.
Set umask as 0077 for all users and services using the pam module. Then override this by setting the umask 0022 for
root
under/etc/environment.d/
. Any valid use case where having a umask of 0077 can be problematic is thus covered and not included in the hardening. System administrators will have this umask when they login.