Hi.

There is an old attack allowing to fish for passwords in OS login forms. 
An attacker starts a GUI application showing a login form identical to 
the OS login form and leaves the computer. A victim wants to log into 
the computer, sees the login form, enters their password, and this 
password is sent to the attacker. A defense against this attack is to 
press Ctrl+Alt+Del (or another hotkey) before entering a password. The 
OS should be configured such that this hotkey opens the OS login form 
and no application is able to disable this hotkey.

Unfortunately, Sway isn't configured with any such hotkey by default. So 
I use the following configuration. Wlgreet is executed with the option 
`--command 'sway --config /etc/sway/user-config'` where 
"/etc/sway/user-config" is
```
include "$HOME/.config/sway/config"
bindsym --to-code Control+Alt+Delete exec swaymsg exit
```
I hope that an attacker has no way to disable this hotkey in Sway. Am I 
correct?

In order to teach users to press Ctrl+Alt+Del before entering a 
password, the following GUI feature is used. When the OS login form 
(wlgreet in this case) is started, it just displays the message "Press 
Ctrl+Alt+Del". Pressing it transfers to the login form. Would you accept 
such a patch for wlgreet?

> ```
> include "$HOME/.config/sway/config"
> bindsym --to-code Control+Alt+Delete exec swaymsg exit
> ```
> I hope that an attacker has no way to disable this hotkey in Sway. Am 
> I correct?


Short answer, no: the attacker could use the unbindsym command to remove 
the bindsym. The attacker would have to have sway IPC access (instead of 
Wayland IPC access), so it depends on how hardened your system is with 
respect to sandboxing. Remember that, if anything untrusted ever 
executed as your user directly outside of a sandbox, you lose - they 
will be able to intercept anything you do and persist their attack 
across sessions.

The attacker can also use the keyboard-shortcuts-inhibit protocol to 
disable keybindings temporarily (meant for e.g. VM consoles or RDP 
sessions), use ext-session-lock to lock the session (in which case only 
--locked bindsyms are active), etc.

The intended way to deal with this is sandboxing, which filters out 
privileged protocols like ext-session-lock and wlr-layer-shell, making 
applications unable to create a window similar to wlgreet in the first 
place.

>
> In order to teach users to press Ctrl+Alt+Del before entering a 
> password, the following GUI feature is used. When the OS login form 
> (wlgreet in this case) is started, it just displays the message "Press 
> Ctrl+Alt+Del". Pressing it transfers to the login form. Would you 
> accept such a patch for wlgreet?
>

What you are proposing is end-user sway configuration, unrelated to 
wlgreet. I also imagine that users would be quite surprised by 
ctrl+alt+del killing their entire session without hesitation, which is 
not at all what the combo does on other OS's - Windows for example 
presents a menu usable for other things like opening Task Manager.

So no, I don't intend on adding this.

On 2/2/25 1:52 PM, Kenny Levinsen wrote:
>> In order to teach users to press Ctrl+Alt+Del before entering a 
>> password, the following GUI feature is used. When the OS login form 
>> (wlgreet in this case) is started, it just displays the message 
>> "Press Ctrl+Alt+Del". Pressing it transfers to the login form. Would 
>> you accept such a patch for wlgreet?
> What you are proposing is end-user sway configuration, unrelated to 
> wlgreet.
On the other hand, the vulnerability may be fixed with systemd and 
greetd as described in 
https://mastodon.social/@pid_eins/113441330932924520 . Are you interested?

On 04/02/2025 17.50, me@beroal.in.ua wrote:
> On the other hand, the vulnerability may be fixed with systemd and 
> greetd as described in 
> https://mastodon.social/@pid_eins/113441330932924520 . Are you 
> interested?


Not really. The way greetd currently manages login makes a greeter 
mutually exclusive with a user session, so it would mean that pressing 
the sequence would have to violently kill the active session, which I am 
not a big fan of. To avoid this it would require making greetd 
"multi-session" in such a way that it can behave as session locker and 
manage multiple ongoing user sessions, which might be a quite 
significant change that I do not currently have plans for.

Login managers also run as root for PAM reasons and can therefore freely 
access input devices at will if they wanted to, which in turn mean that 
the logind feature doesn't actually enable anything new that wasn't 
already possible. It's just a nudge.