Summary of the security discussions around Wayland and privileged clients

[Dodier-Lazaro, Steve]

Hello Jasper,

A quick reply on some of your emails (grouped to avoid spamming  the ML).

> My experience with PAM and similar "pluggable security modules" is that
> they provide a subpar user experience, are hard to integrate properly into
> the system, and have large pain points that stem from having such
> flexibility.

I'm really unsure what you mean by subpar UX here. Subpar involves a comparison 
with another approach, but then it'd be easier for us to discuss what you think 
is wrong in PAM if you told us what you think would work better and why. 
Otherwise it's hard for us to see the parallel you're making with WSMs and 
understand what it is you're concerned about and what we should do about those 
concerns.

> My compositor, mutter, will probably never call out to your "WSM", and
> we'll probably defer to another application authorization mechanism,
> probably the same one that provides application sandboxing, and other such
> capabilities. I'd also recommend that you go ahead and talk to the people,
> and perhaps even help build that mechanism, which isn't specific to
> Wayland, but will also cover DBus requests, system calls, and more.

The idea of security modules is not that you decide which modules to speak to or
what modules do, but rather that a number of operations in your compositor can 
cause security issues, and that these operations can be monitored and a policy 
enforced over them. What Martin speaks about in his blog post is mostly the 
infrastructure allowing this, in short he's thinking about how to implement 
complete mediation of the interactions between apps that occur in the graphic 
stack. WSMs are then pieces of code that can use these hooks to decide what 
policy to implement. To a certain extent we also discuss what we believe would 
be a sensible (wrt. the current reasonable requirements of apps found on Linux 
systems, usability requirements and security requirements) default policy for a 
default WSM to enforce. 

It's not really relevant to you what the WSM does or why. A default policy would
make sure that an app cannot spy on another at the graphic stack level (and this
has direct consequences for e.g. when you're typing a password in a dialog - it
may just stay in the corresponding process's memory and never be dumped to disk,
hence a security benefit already). Of course a WSM will never mediate file 
system accesses, but that is not the point of it. What matters is that Wayland
and compositors are the only place where you can put infrastructure for graphic
stack security. I'm currently working on implement a system with app sandboxing,
and I have my own subjective and debatable idea of what the policy should be and
I would expect others to disagree with me on this. Yet, what matters to me is
that there is a mediation infrastructure that is flexible and complete enough
for me to enforce the policy I want. It's the case in certain aspects of the
system with SELinux, it's not the case at all in many many areas of userland
(not relevant to this email to discuss that) including the graphic stack (even
XACE does not allow me to implement a simple/easy clipboard access policy). It's
not really ok to state that since other threats exist on a system then it's not
worth finding responses to threats in one's own code base (saying that it's not
necessary to isolate windows in Wayland because they can steal one another's
file is a bit like saying that session passwords are useless because one might
as well steal a computer's HDD and read the data from there. Turns out this
becomes false on the day people fix the HDD-related threat with full-disk
encryption).

The whole goal of discussing WSMs and discussing what a policy could look like
is making sure that we (well, you Wayland developers, actually) don't forget to
mediate some operations that may be exploited to harm users' assets later on --
irrespective of whether other threats in other subsystems of an OS exist.

> Of course. That's why I'd love to have not just a "WSM" but a full
> application authorization system that can be used not only for Wayland
> requests but correspond to full capability management.

Nothing prevents a WSM from collaborating with a LSM and some other types of 
SMs! However without infrastructure for WSMs in the first place, then people
like me would have to dump X11/Wayland/whatever's out there and rewrite a whole
graphic stack. Ouch! We do need to bring security to userland incrementally
because there is so much to fix, but yes the default policy will have to
encompass more aspects than just who shares what GPU buffers.

> DBus is a perfect example. We should allow an app to only see the DBus
> peers that it needs to see. So, org.gnome.Photos should never be able to
> see or call APIs on org.kde.Konqueror or vice versa. But an app might want
> a capability to interface with org.freedesktop.Telepathy. And the same app
> might want access to a privileged wl_notification_shell API so it can
> display a chat window in a special corner of the screen when you get a
> message. And they'd probably want read/write access to "~/Personal
> Data/Chat Logs/" or wherever the user configured their chat logs folder to
> be, without access to "~/Porn/"

Here you're not speaking about infrastructure but policy. Who decides who's
allowed to use the gnome photo service? Who enforces that? How does the user
manipulate such a system, how can an adversary running their own malicious app
influence on the system and what can they do? It seems to me that in your
example you identify the need to mediate DBus communication (SELinux apparently
does that through LSM) and FS access (that's done by most LSMs). Likewise, we
need to secure Wayland so that if people want a policy to prevent keyloggers and
screenshots of your bank PIN, they can do it.

Thinking about the full surface from which threats may arise does not require
thinking about everything at the same time and trying to cram different systems
with different types of IPC protocols / workflows into one single policy logic.
You can already abstract from all of that and provide reasonable standards of
security/usability in each subsystem whilst assuming that other consciencous
developers will do the same with their own code (or alternatively, that
consciencious distributors will build a consistent UX with decent security, by
combining only those subsystems that allow for a security policy to exist).

When you develop mutter as a compositor, you may want to have it obey whatever
the WSM does because maybe you cannot predict who will use mutter and for what,
and what security policy they will need. If you hardcode a policy in mutter, or
just if mutter decides what parts of a policy to obey and what parts to ignore,
how can a security expert / distributor / user reliably enforce a policy? Will
you provide your own policy edition interface? How will it differ from a WSM?
Would it not be better to share collective experience and know-how and make
something that works for everyone now and hopefully in 20 years time?

Finally what prevents you from putting your GNOME distributor hat later on and
implementing the WSM that you think is best for GNOME users? This way you'd
still let downstream projects adjust to their needs or to whatever threats occur
in the future. Maybe a distributor/developer like me will have a different logic
to their security policy and want to have their own WSM and then they will be
responsible for providing a good UX with their policy and your software.

Thanks,
--
Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670