Summary of the security discussions around Wayland and privileged clients

Thu Feb 27 09:01:55 PST 2014

On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick <
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.

Your pluggable WSM just made the user unhappy.

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>
>> 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
>>
>>> [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)](http://www.nsa.gov/research/_files/selinux/
>> papers/module/x45.shtml
>>
>>> [2]) or [X Access Control Extension
>>>>
>>>>
>>>  (XACE)](http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
>>
>>> [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 lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel [4]
>>>
>>
>> --
>>   Jasper
>>
>>
>> Links:
>> ------
>> [1]
>> https://www.mail-archive.com/Wayland-devel@lists.
>> freedesktop.org/msg12261.html
>> [2] http://www.nsa.gov/research/_files/selinux/papers/module/x45.shtml
>> [3] http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
>> [4] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
> _______________________________________________
> 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/20140227/750cda9f/attachment-0001.html>