Open 0xDkXy opened 1 year ago
As of now, it is not. It has occurred to me, but it seems very difficult.
As for X11, I remember reading somewhere that implementing an X11 lock screen securely is basically impossible. I don't know enough about Wayland to tell you how it works over there.
Anyway, it would be inherently difficult as Lemurs runs in a TTY and the session is graphical. As I see it we have 3 options:
As for now, I will mark it as a wontfix
. If someone has an ingenious idea or better understands how this would function on X11 or Wayland. Kindly let me know.
I believe the blog post you're thinking of is this one: https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
The biggest reasons why some of the current lock screen implementations have security flaws is that if they crash then it automatically gives you access. So an attacker just do things like mash the keyboard and try to deliberately crash the lock screen. So the goal becomes then to minimize the possibility of crashes in the critical section that handles the actual locking/unlocking. I believe Rust can help us a lot here.
As far as the mechanism, the TTY switch approach is what is taken by light-locker which is used as a lock screen implementation for LightDM. It locks the current session, starts a new greeter in a different VT. Disables VT switching, and upon successful auth switches to the original session. It is able to do all this despite LightDM not even knowing the existence of light-locker.
We have the advantage in the sense that we can have lemurs be aware of the locking mechanism. Lock the current session, start the auth screen in a different TTY (in a separate process) and if the auth succeeds we unlock the current session and switch back.
I do not have any idea of how this would work on Wayland since I have never used it, but we can probably do a good lockscreen implementation for X as long as we minimize the likelihood of crashes.
I believe Rust can help us a lot here.
It is still quite difficult to ensure Lemurs does not panic, but we should be able to have proper cleanup once a panic happens. This gives us an advantage, but it is still quite difficult.
As far as the mechanism, the TTY switch approach is what is taken by light-locker which is used as a lock screen implementation for LightDM.
I am not sure how applicable this is to lemurs since we are not in a X11 session, however the vlock
approach is very interesting and I would be open for looking at that. Looking at the source code there. Porting would also not be completely impossible.
I do not have any idea of how this would work on Wayland since I have never used it, but we can probably do a good lockscreen implementation for X as long as we minimize the likelihood of crashes.
As far as I am aware, Wayland has a session locking
protocol. This requests a session lock from a wayland compositor. Each compositor then deals with it in their on way. I believe hyper land just allows you to run a command when a session lock is requested.
Overal, it is not a simple task, but it is at least not impossible as I originally thought. Maybe, very maybe, this would be something I would be interested in.
One of the immediate other problems I can foresee. Also looking at vlock
is external monitors. Since we don't have access to xrandr or the wayland equivalent, people need to have their monitors setup within GRUB or some other boot level process to display the lock-screen on the correct display.
As the title. If not, I figure that it wound be a good idea to make it.