Summary of the security discussions around Wayland and privileged clients

[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> 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](
>> https://www.mail-archive.com/Wayland-devel@lists.freedesktop.org/
>> msg12261.html) (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)](http://www.nsa.gov/research/_files/selinux/
>> papers/module/x45.shtml) or [X Access Control Extension (XACE)](
>> http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html).
>>
>> 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 lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140226/94331bf5/attachment.html>