Skip to content

Conversation

@monsieuremre
Copy link
Contributor

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.

@adrelanos
Copy link
Member

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 #185), add to https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation and test what you can?

@monsieuremre
Copy link
Contributor Author

Could you please create a list of different environments (mentions in #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.

@adrelanos
Copy link
Member

What do you mean?

  • sudo su
  • su
  • ssh login as user
  • ssh login as root
  • login on virtual terminal as user
    • login on virtual terminal as root
  • X11 login
  • Wayland login
  • Qubes dom0 sudo xl console vmname
  • ... as mentioned in that ticket

@monsieuremre
Copy link
Contributor Author

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.

@adrelanos
Copy link
Member

adrelanos commented Jan 26, 2024 via email

@adrelanos
Copy link
Member

Stalled.

Superseded by:

@adrelanos adrelanos closed this Nov 29, 2024
@monsieuremre monsieuremre deleted the patch-2 branch November 29, 2024 13:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants