Summary of the security discussions around Wayland and privileged clients
sebastian at sebastianwick.net
Wed Feb 26 19:02:25 PST 2014
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 free.fr>
>> 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
>>> ) (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
>>> ) or [X Access Control Extension
>>> 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
>>> 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.
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel 
>  http://www.nsa.gov/research/_files/selinux/papers/module/x45.shtml
>  http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
>  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel