Summary of the security discussions around Wayland and privileged clients

Sebastian Wick sebastian at
Wed Feb 26 19:02:25 PST 2014

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?

Am 2014-02-26 23:05, schrieb Jasper St. Pierre:
> Hi Martin,
> 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.
> 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.
> On Wed, Feb 26, 2014 at 4:40 PM, Martin Peres <martin.peres at>
> wrote:
>> Le 19/02/2014 17:11, Martin Peres a écrit :
>>> #### Wayland Security Modules
>>> As seen earlier, granting access to a restricted interface or not
>>> depends on the context of the client (how it was launched,
>>> previous actions). The expected behaviour should be defined by a
>>> security policy.
>>> As no consensus on the policy [can apparently be
> reached](
>>> [1]) (as usual in security), we have all agreed that we needed to
>>> separate the policy from the code. This is very much alike [Linux
>>> Security Modules
> (LSM)](
>>> [2]) or [X Access Control Extension
> (XACE)](
>>> [3]).
>>> From a software engineering point of view, we would work on a
>>> security library called Wayland Security Modules (name subject to
>>> changes) that Wayland compositors would call when a security
>>> decision would need to be made. The library would then load the
>>> wanted security policy, defined by a shared-object that I will
>>> refer to as the security backend. In the case of allowing a client
>>> to bind a restricted interface or not, the corresponding WSM hook
>>> should return ``ACCEPT``, ``PROMPT`` or ``DENY``, prompt meaning
>>> the compositor would have to ask the user if he wants to accept
>>> the risk or not. Let me stress out that prompting should be a
>>> last-resort measure as numerous studies have been made proving
>>> that unless asked very rarely, users will always allow the
>>> operation.
>>> Some additional hooks would also be needed in order to track the
>>> state of Wayland clients (open, close, etc...) but nothing too
>>> major should be needed. The compositors would just have to store
>>> this context in a ``void *security;`` attribute in the Wayland
>>> client structure. Finally, WSM could be extended to control the
>>> access to the clipboard and maybe other interfaces I haven't
>>> thought about yet.
>>> The design of this library has not started yet. If you are
>>> interested in helping out, I would love to have some feedback on
>>> what are your use cases for WSM.
>> Hey Guys,
>> I think I'll start working on this lib pretty soon. If you have any
>> objection towards going down this path, please voice them now.
>> Also, do you think we should allow stacking security modules or
>> not? For simplicity reasons, I don't think I'll allow it, but some
>> one of you may have compelling reasons to allow it.
>> Cheers,
>> Martin
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at
>> [4]
> --
>   Jasper
> Links:
> ------
> [1]
> [2]
> [3]
> [4]
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at

More information about the wayland-devel mailing list