[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Restrict root access

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 (
https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html
).

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.

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.

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Eliminate_stat/notify-based_device_sidechannels

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:

https://mjg59.dreamwidth.org/55105.html

1 Like

A post was split to a new topic: Eliminate LD_PRELOAD and other Dangerous Environment Variables

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.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]