It appears that environment scrubbing won’t be a solution after all. I think it only applies to profile transitions i.e. transitioning from init-systemd to another profile. So we can’t just enable it globally to get rid of LD_PRELOAD.
The issue with enabling it globally I talked about in the apparmor-profile-everything thread was to do with /lib. If you exclude just that, you can get near-global environment scrubbing. Testing LD_PRELOAD with hardened_malloc and cat /proc/self/maps still worked fine indicating it’s not effective for non-profile transitions.
This is also further backed up by the fact that there is no environment scrubbing available for the ix permission. Only permissions that transition profiles do such as Px or Cx.
If you say Y here, timing analyses on block or character devices like /dev/ptmx using stat or inotify/dnotify/fanotify will be thwarted for unprivileged users. If a process without CAP_MKNOD stats such a device, the last access and last modify times will match the device’s create time. No access or modify events will be triggered through inotify/dnotify/fanotify for such devices.
This feature will prevent attacks that may at a minimum allow an attacker to determine the administrator’s password length.
Thankfully, linux-hardened has this.
Will need to do more research to see how dangerous this is. I’ll add it to the wiki.
Our current restrictions on sudo would not prevent an attacker from exploiting an actual vulnerability in the program itself. For example, the widely-publicised buffer overflow vulnerability discovered a few months ago can still be exploited to gain root access. sudo is a very complex program and is setuid so vulnerabilities in it can allow privilege escalation, regardless of our root access restrictions. To help against this, we can restrict the file permissions of the executable to only allow users within group sudo to execute it at all in the first place. This will prevent e.g. a compromised sdwdate user from exploiting it.
@Patrick in which package would the above permission change best be suited? We could use permission-hardening in security-misc, although that may be too invasive for a general (i.e. not just Whonix) security package so a permission-hardening drop-in config file in dist-base-files or similar may be better.
Where/how we enable SUID Disabler and Permission Hardener by deafult when time has come is a different question. Might be too heavy for security-misc indeed. But doesn’t really belong to dist-base-files either.
What if we create a second group for access to sudo like sudo-access or sudo-execute and then add the necessary users to it in Debian postinst scripts? Or maybe create a script that parses /etc/sudoers.d? Then there would be two groups: one for filesystem access and one for sudo’s internal authorisation.