Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

On 27/02/2014 18:01, Jasper St. Pierre wrote:
> On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick 
> <sebastian at sebastianwick.net <mailto:sebastian at sebastianwick.net>> wrote:
>
>     Hey Jasper,
>
>     maybe I didn't understand what you're saying but why can't you use
>     the application authorization mechanism you're talking about in a
>     "WSM"? Wouldn't it make sense to make it independent of the
>     compositor?
>
>
> 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.
>
> 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/".
>
> We need to think about the full surface of how applications will 
> interact with the system, without thinking about it in terms of 
> Wayland-only or DBus-only specifics. That's why I'm opposed to the 
> idea of "WSMs", and instead say we should start thinking about a full 
> application sandboxing and capability mechanism.
>
> For a system like GNOME, for which our compositor, mutter, is used, 
> I'd never allow a different WSM to be configured, because then it 
> won't integrate with the rest of the system. A dialog pops up to ask 
> the user to allow wl_notification_shell, but they still can't use 
> org.freedesktop.Telepathy.

I think the policy should be compositor-agnostic, especially since some 
may run multiple compositors at the same time. We thus need to abstract 
the different compositors and I think that's the role of libwsm.

Just like LSM (Linux Security Module), libwsm is just a collection of 
hooks that get called with a well-defined semantic, most-likely mostly 
based on the Wayland protocol rather than the internal implementation of 
the compositor.

Libwsm would indeed ship with a default policy that doesn't depend on 
anything else than POSIX but it could be replaced very easily to use any 
security decision engine, may it be SELinux or whatever new and shiny 
decision engine appears in the future. The way I intend to do that is by 
having libwsm forward the hooks to the right security backend. A 
security backend would be a dynamically loaded .so by libwsm. libwsm 
will know which .so should be loaded by reading its configuration file. 
I already implemented such a system in PPassKeeper[1].

Just to make it clear, if no such abstraction is made, then all 
compositors will require changes when a new decision engine becomes 
available. But the worst problem is that each compositor will have 
different hook points with different semantics and this will require to 
write a different policy for each and every compositor. If I may say, I 
think it sucks hard ;)

>
> Your pluggable WSM just made the user unhappy.

You're killing the messenger, not the problem ;). In this case, the 
problem would be the policy. WSM isn't PAM, I think having WSM only load 
ONE security backend is just easier and simpler.

Cheers,
Martin

[1] http://www.mupuf.org/project/ppasskeeper.html