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

Restrict root access

OK.

interpreter lock doesn’t necessarily have to become a default enabled feature. That’s actually unlikely. Not sure yet.

On top of user / admin / superadmin boot modes, users who boot into user mode could choose to turn that user user into a additionally restricted user (new term required also vs normal user user). In such a mode the user would only be able to do a few things such as starting high risk applications. Or perhaps for example one mode would only allow to run Tor Browser but nothing else. Suppose the Tor Browser process would be compromised, the attacker couldn’t do much if we suppose /home/, /tmp, etc. noexec, interpreter lock, restricted shell, apparmor, sandbox, and whatnot. That would be similar to Chromium OS (which has interpreter lock) or Android. I.e. some users might choose to reduce the functionality of their VM in order to get better security.

Yes. The concept is good.
Though the actual implementation of rbash at is quite limited
But maybe that could be improved. Perhaps such fixed restricted shells already exist.

The DISPLAY variable is just to start imagination. Maybe apparmor, sandbox, restricted shell or something could prohibit from setting the DISPLAY variable? Or some other environment variable? Or DISPLAY (or so) containing a random hash which cannot be guessed/find out by the attacker?

1 Like

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 (
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.

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