Interpreter lock should fix that. Deny execution of the real shells and only allow rbash.
1 Like
^ the LD_PRELOAD thing I was talking about.
I think we should just enable environment scrubbing globally in apparmor-profile-everything and sandbox-app-launcher.
hardened_malloc isn’t a big issue currently as we aren’t using it for much yet. If we want to use it, we can just set it in /etc/ld.so.preload. I don’t see much breakage with it anyway.
2 Likes
Use case?
Threat scenario: compromised user user but no root compromise.
If one can log keystrokes and view all data in /home/user, I don’t see much extra harm with LD_PRELOAD.
LD_PRELOAD prevention would lower attack surface for root compromise if combined with noexec? Then no new, extra, arbitrary code could be downloaded/created executed? That might depend on the type of exploit used to gain user user compromise.
1 Like
LD_PRELOAD is how they can log keystrokes.
For example, you aren’t storing your passwords in /home/user (I hope) but you are entering them into websites in your browser. LD_PRELOAD can hook into the browser and grab passwords.
If an attacker can set LD_PRELOAD globally, security in the user’s session is basically non-existent. Not even sandboxing etc. would help as they can just hook into the sandbox program too.
LD_PRELOAD can also likely introduce new arbitrary code to bypass noexec/TPE/apparmor execution restrictions. They can probably run
LD_PRELOAD=/path/to/malicious_libary /bin/echo test
that redefines printf() to a new function that exploits some vulnerability.
1 Like
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.
We’d need to disable LD_PRELOAD in another way.
1 Like
madaidan via Whonix Forum:
LD_PRELOAD is how they can log keystrokes.
Also xinput (
).
For example, you aren’t storing your passwords in /home/user (I hope) but you are entering them into websites in your browser. LD_PRELOAD can hook into the browser and grab passwords.
If an attacker can set LD_PRELOAD globally, security in the user’s session is basically non-existent. Not even sandboxing etc. would help as they can just hook into the sandbox program too.
LD_PRELOAD can also likely introduce new arbitrary code to bypass
noexec/TPE/apparmor execution restrictions. They can probably runLD_PRELOAD=/path/to/malicious_libary /bin/echo testthat redefines
printf()to a new function that exploits some vulnerability.
These are really good reasons. Needs to be documented when implemented.
1 Like
There are some device timing sidechannels that may be dangerous although I’ve not seen proof of them being used as a full-blown keylogger yet. Grsecurity fixed this by restricting them to CAP_MKNOD.
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.
1 Like
The number of ways the lockdown patches increases root / kernel separation. Can be useful to see what needs to be done besides toggling the sysctl when 5.4 hits:
1 Like
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.
2 Likes
@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.
/usr/bin/sudo 4750 root sudo
Seems to work fine for me.
1 Like
Since SUID Disabler and Permission Hardener is (not yet) default in (security-misc | Whonix | Kicksecure) anyhow, I guess adding to security-misc config folder would be OK.
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.
1 Like
1 Like
Merged.
1 Like
Happening in Qubes-Whonix:
upgrade-nonroot
/usr/bin/upgrade-nonroot: line 8: /usr/bin/sudo: Permission denied
As said earlier, elsewhere, I don’t consider upgrade-nonroot too important. Could be phased out.
Unrelated to Qubes-Whonix. Applying to all Whonix / Kicksecure…
Other things likely broken:
- whonix-xfce-desktop-config /usr/share/livecheck/livecheck.sh
- sdwdate-gui /usr/lib/sdwdate-gui/log-viewer
- Probably other uses of sudo.
mygrep -r -i --invert-match “#|man/” | grep --color "sudo "
Things confirmed broken:
- systemcheck
1 Like
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.
1 Like
That sounds like a good idea! Patches welcome. Seems like quite a lot to work through.
Alternatively these uses of sudo could also be reviewed / implemented any other way so sudo can be avoided and perhaps this solution can be avoided as well.
Seems harder to do and get right. Perhaps an APT trigger.
Will out comment this for now due to breakage mentioned above.
1 Like
1 Like