LWN: Comments on "The status of Wayland security"

Audio security?

eean — Sat, 15 Mar 2014 07:46:18 +0000

I do have a two seat system, but I share one sound card/speakers so security isn't really an issue. Or at least I don't see how it is.

--system for sure isn't a prereq for properly handling a normal multiseat setup where there's one sound card per seat (though I'm not sure if Linux is multiseat aware enough to do it in practice.) But ideally you would just have one pulseaudio process per sound card and it would just work.

So what is your use case?

> On a tangent: Is there a plan for being able to securely mix *audio* from mutually mistrusting applications?

Isn't this a separate question from having only one sound server/system? Or are you assuming processes of the same user trust each other? The equivalent to the Wayland issue described would be PulseAudio granting special permission to access the mic or be pavucontrol.

Audio security?

idupree — Fri, 14 Mar 2014 04:39:07 +0000

On a tangent: Is there a plan for being able to securely mix *audio* from mutually mistrusting applications? PulseAudio and JACK both avow that securely mixing audio from multiple users is a non-goal:

`pulseaudio --system`: http://www.freedesktop.org/wiki/Software/PulseAudio/Docum...

JACK_PROMISCUOUS_SERVER: see e.g. https://wiki.archlinux.org/index.php/JACK_Audio_Connectio...

The status of Wayland security

nybble41 — Thu, 13 Mar 2014 17:58:37 +0000

> 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.

The status of Wayland security

dgm — Thu, 13 Mar 2014 17:14:18 +0000

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

raven667 — Thu, 13 Mar 2014 16:29:29 +0000

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

tialaramex — Thu, 13 Mar 2014 15:58:57 +0000

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

SLi — Thu, 13 Mar 2014 10:31:17 +0000

"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.