The status of Wayland security

Posted Mar 13, 2014 10:31 UTC (Thu) by SLi (subscriber, #53131)
Parent article: The status of Wayland security

"Screen lockers need to capture all input" seems true only to the extent they are implemented in the same crappy way as they are currently in X.

Treating a screen locker as "just another client" that just happens to capture all input is a hack that works to an extent as long as you don't want to do anything too unusual. It also opens surprising attack routes.

In my opinion screen locking is perhaps the one thing that Windows does right. In a multi-user environment, the user needs to be able to be sure he's typing his password into a genuine login prompt, not something that merely resembles it. Windows solves this by using a keyboard shortcut that cannot be captured by (non-privileged) programs, namely ctrl-alt-del. After pressing ctrl-alt-del you can be absolutely sure you are talking to an admin-sanctioned part of the OS installation.

The status of Wayland security

Posted Mar 13, 2014 15:58 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (1 responses)

Hmm.

Ctrl-Alt-Del is a SAK (Secure Attention Key)

Linux implements a SAK but it is rarely used for anything relevant here

However, the first thing that happens when you press the SAK in Windows is that it summons a separate desktop, and that means it captures all input. So I don't think Windows is behaving so differently as you think in this regard.

The status of Wayland security

Posted Mar 13, 2014 16:29 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think the hair being split here is that the input security is a property that falls out as a consequence of switching to a private desktop (and that switching being robust) and is not a special property of the password-accepting application window and is not happening "in-band" of the users desktop.

I think this approach to work around key loggers has merit but only so far as the OS commits to it, and the user can identify when they are being phished, any password dialogs which happen in-band of the users desktop reduce the effectiveness of this design, even in Windows the local users password is accepted in dialogs, when changing privileged settings for example, that doesn't require a SAK to initiate the dialog.

The status of Wayland security

Posted Mar 13, 2014 17:14 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

In fact, I believe that for Wayland the best route will be exactly opposite: a screen locker needs no user input at all, it should only put pretty graphics on screen. Let the compositor lock the screen and ask for user input.

The status of Wayland security

Posted Mar 13, 2014 17:58 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> a screen locker needs no user input at all, it should only put pretty graphics on screen

I suppose that would depend on what you mean by "screen locker". I would define the screen locker as the program responsible for authenticating the user and unlocking the screen. Regardless of whether that task is built into the same binary as the compositor or outsourced to a privileged helper program, the "screen saver" portion could be left to an unprivileged process with no access to user input. There may well be good reason--privilege separate, flexibility, customization--to separate the authentication part from the compositor. That doesn't mean the purely decorative portion of the lock screen stack needs to be similarly privileged.