Qubes R4.3 is using xfce4-screensaver for screen locker. I don’t trust DE to deliver a secure screenlocker. What alternatives are other people using? Meanwhile I will install xscreensaver again, tho it’s not ideal either
Uh, qubes used to have it’s own screen locker, the fact that they changed it must mean that the standard one is pretty good, why would they downgrade otherwise
In the other hand this is an advise I got from a friend of mine a year back:
find any old flash drive, encrypt it and store a hash or something in it, have sys-usb auto connect that USB to a sys-unlock, create an entry to /etc/mounts and crypttab to auto unlock that usb and send the hash to dom0 every second or so, then create a Pam file to check delivered hashes from sys-unlock and it it matches then enable no password unlock for the user and disable that Pam setting after a second, lastly disable password unlock completely
Its not xfce lock screen that is insecure, its where in memory does Linux store xfce-lockscreen and if there is a way for someone to manipulate that, but yet AGAIN Pam does the unlocking
Nevertheless the Pam USB key trick shouldn’t take more then a couple hours to setup and an hour or two more to make sure it is hardened enough, even with an AI’s help I mean
Wow that has never happened in any lockscreen on linux, qubes or bsd foe me at least so I did not know that was a thing, that’s a bummer, maybe they the lockscreen from suckless.org?
Not really, this decryption of the usb happens in a vm disconnected from the internet, the USB never has knowledge of your decryption key so even if it was swapped with a mini computer for any reason the only valid attack vector is to acquire the computer, wait a few years for a backdoor to be released and insert one such USB in, assuming you keep your staff updated I don’t see a reason to fear such technique, unless you can explain any attack vectors you see possible
Edit: I think it was apparent from the comment you where replying on but I have not tried this method out, nevertheless I don’t see a lot of attack vectors in this method, also an update to the last comment, I think the method was to store an RSA private key in the encrypted USB not a hash so I have to correct myself here
qrexec calls are slow, take a lot of resources and are unreliable. it’s a bad idea to expect them to execute like clockwork every second
also the whole point of isolating dom0 is to prevent untrusted domains from sending data to it. that’s why even the shared clipboard is not exposed to dom0. there are a few exceptions, like datetime synchronization. but you can see in the code of qvm-sync-clock the lengths it goes to sanitize input