change default umask

Development
21

config-package-dev displace and copyright is sorted.

1 Like
22

This needs to be re-checked with every distribution upgrade. For example systemd causes an issue:

This might be inconsistent depending on from where files are created. Could you please test all of the various options?

  • sudo su
  • sudo -u man bash
  • sudo su
  • sudo login
  • sudo sulogin
  • virtual console
  • boot emergency console (maintenance mode)
  • from scripts
  • any any others that you might have in mind?
1 Like
23

This got me 0026 instead of the expected 0006. Same for sudo sulogin too.

The rest were all fine.

1 Like
24

So we have two programs/packages that ignore umask.

dpkg -S `sudo which sulogin`
util-linux: /sbin/sulogin

And

dpkg -S `sudo which sudo`
sudo: /usr/bin/sudo

Could you please check if there are bug reports / report bugs / find workaround for these?

1 Like
25

I can’t find anything. Maybe it’s just a thing on my end. Does the issue replicate for you?

1 Like
26

Same issue for me.

ls -la a
-rw-rw-r-- 1 root root 0 Jul 1 11:30 a
ls -la a
-rw-rw-r-- 1 root root 0 Jul 1 11:30 a

1 Like
27

We should probably make a bug report then.

1 Like
28
1 Like
29
1 Like
30

Still getting this error.

Jul 07 22:29:11 host sudo[4089]: PAM unable to dlopen(pam_cgfs.so): /lib/security/pam_cgfs.so: cannot open shared object file: No such file or directory
Jul 07 22:29:11 host sudo[4089]: PAM adding faulty module: pam_cgfs.so

Do we need to depend on package Debian -- Details of package libpam-cgfs in buster?

Or what is line

session optional pam_cgfs.so -c freezer,memory,name=systemd

in our https://github.com/Whonix/security-misc/blob/master/etc/pam.d/common-session.security-misc good for? It’s a Debian default, right? So I am wondering why I never saw this bug before.

1 Like
31

Removing the pam_cgfs.so line or installing libpam-cgfs fixes the error.

It seems to be useful for creating cgroups and unprivileged containers like with LXC.

1 Like
32

Added dependency so we can stay as close to upstream default as sanely possible.

1 Like
33
1 Like
34

Since users who upgraded don’t benefit from these default umask changes (files already created using Debian default umask where other users have read access by default)… What do you think about running the following command once as root from a security-misc Debian package maintainer script?

for folder_name in /home/* ; do
    chmod o-rwx "$folder_name"
done

This should probably also be done during account creating during boot.

This would help all users who haven’t had files leaked but who in future will have any non-root user being compromised since if others (i.e. non-group members) don’t have read access to /home/user then they also cannot read any files lets say /home/user/some-document even if it has default umask where others have read access?

1 Like
35

This was implemented but could be disabled if there is a good argument against it.

1 Like
36

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
1 Like
37

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.

1 Like
38

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.

1 Like
39
1 Like
40
2 Likes