Enable umask hardening

[ArrayBolt3]

This pull request enables umask hardening, preventing unauthorized access to user-created files.

Changes

• Reinstates [/usr/share/pam-configs/umask-security-misc](https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/umask-security-misc), which sets a restrictive umask of 027 by default for all logins.
• Adds sudoers configuration to /etc/sudoers.d/security-misc that sets the umask to a less restrictive setting of 022.
• Updates README.md as appropriate.

Mandatory Checklist

• Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

Optional Checklist

The following items are optional but might be requested in certain cases.

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

Fixes #185

Notes

The following scenarios should be covered properly and have their umask set appropriately with this configuration:

• Console login
  • Goes through PAM, thus set to 027 for users and 022 for root
• Graphical login
  • Goes through PAM, thus set to 027 for users
• SSH login
  • Goes through PAM on Debian, thus set to 027 for users and 022 for root
• Graphical remote management
  • Tools that reuse a session (x11vnc, etc.)
    • Requires a pre-existing login, which goes through PAM, thus set to 027 for users
  • Tools that create a new session (xrdp)
    • Will depend on the tool, xrdp goes through PAM, thus set to 027 for users
• Privilege escalation
  • umask overridden to 022 via sudoers configuration, thus when escalating from user to root or to any other user, umask will become 022
    • Worthy of note, this will affect escalations to users like debian-tor as well. Additionally, when dropping privileges from root to a non-root user, the non-root shell will still have umask set to 022. This may or may not be considered intended behavior, but is probably safest for a default. Users who wish to change this can modify ~/.profile and ~/.zprofile to set umask to 027 or any other preferred value.

System services are considered out-of-scope, systemd manages the umask for those via the UMask setting in systemd units.

[monsieuremre]

Very interesting indeed. It seems to achieve the coverage we would want. If it works as intended, this would be a very good way of dealing with umask.

Systemd units not being covered is actually normal. This has to be set in the respective unit files. I am a proponent of setting the strong umask for all systemd units per default. But this would be another topic I think.