<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick <span dir="ltr"><<a href="mailto:sebastian@sebastianwick.net" target="_blank">sebastian@sebastianwick.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Jasper,<br>
<br>
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?<br>
</blockquote><div></div><br></div><div class="gmail_quote">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.<br>
<br></div><div class="gmail_quote">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/".<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br>
<br></div><div class="gmail_quote">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.<br>
<br></div><div class="gmail_quote">Your pluggable WSM just made the user unhappy.<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Am 2014-02-26 23:05, schrieb Jasper St. Pierre:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
Hi Martin,<br>
<br>
My experience with PAM and similar "pluggable security modules" is<br>
that they provide a subpar user experience, are hard to integrate<br>
properly into the system, and have large pain points that stem from<br>
having such flexibility.<br>
<br>
My compositor, mutter, will probably never call out to your "WSM", and<br>
we'll probably defer to another application authorization mechanism,<br>
probably the same one that provides application sandboxing, and other<br>
such capabilities. I'd also recommend that you go ahead and talk to<br>
the people, and perhaps even help build that mechanism, which isn't<br>
specific to Wayland, but will also cover DBus requests, system calls,<br>
and more.<br>
<br>
On Wed, Feb 26, 2014 at 4:40 PM, Martin Peres <<a href="mailto:martin.peres@free.fr" target="_blank">martin.peres@free.fr</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Le 19/02/2014 17:11, Martin Peres a écrit :<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
#### Wayland Security Modules<br>
<br>
As seen earlier, granting access to a restricted interface or not<br>
depends on the context of the client (how it was launched,<br>
previous actions). The expected behaviour should be defined by a<br>
security policy.<br>
<br>
As no consensus on the policy [can apparently be<br>
<br>
</blockquote>
<br>
</blockquote>
reached](<a href="https://www.mail-archive.com/Wayland-devel@lists.freedesktop.org/msg12261.html" target="_blank">https://www.mail-<u></u>archive.com/Wayland-devel@<u></u>lists.freedesktop.org/<u></u>msg12261.html</a><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1]) (as usual in security), we have all agreed that we needed to<div class=""><br>
separate the policy from the code. This is very much alike [Linux<br>
Security Modules<br>
<br>
</div></blockquote>
<br>
</blockquote>
(LSM)](<a href="http://www.nsa.gov/research/_files/selinux/papers/module/x45.shtml" target="_blank">http://www.nsa.gov/<u></u>research/_files/selinux/<u></u>papers/module/x45.shtml</a><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[2]) or [X Access Control Extension<br>
<br>
</blockquote>
<br>
</blockquote>
(XACE)](<a href="http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html" target="_blank">http://www.x.org/<u></u>releases/X11R7.5/doc/security/<u></u>XACE-Spec.html</a><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[3]).<div><div class="h5"><br>
<br>
>From a software engineering point of view, we would work on a<br>
security library called Wayland Security Modules (name subject to<br>
changes) that Wayland compositors would call when a security<br>
decision would need to be made. The library would then load the<br>
wanted security policy, defined by a shared-object that I will<br>
refer to as the security backend. In the case of allowing a client<br>
to bind a restricted interface or not, the corresponding WSM hook<br>
should return ``ACCEPT``, ``PROMPT`` or ``DENY``, prompt meaning<br>
the compositor would have to ask the user if he wants to accept<br>
the risk or not. Let me stress out that prompting should be a<br>
last-resort measure as numerous studies have been made proving<br>
that unless asked very rarely, users will always allow the<br>
operation.<br>
<br>
Some additional hooks would also be needed in order to track the<br>
state of Wayland clients (open, close, etc...) but nothing too<br>
major should be needed. The compositors would just have to store<br>
this context in a ``void *security;`` attribute in the Wayland<br>
client structure. Finally, WSM could be extended to control the<br>
access to the clipboard and maybe other interfaces I haven't<br>
thought about yet.<br>
<br>
The design of this library has not started yet. If you are<br>
interested in helping out, I would love to have some feedback on<br>
what are your use cases for WSM.<br>
</div></div></blockquote><div><div class="h5">
<br>
Hey Guys,<br>
<br>
I think I'll start working on this lib pretty soon. If you have any<br>
objection towards going down this path, please voice them now.<br>
<br>
Also, do you think we should allow stacking security modules or<br>
not? For simplicity reasons, I don't think I'll allow it, but some<br>
one of you may have compelling reasons to allow it.<br>
<br>
Cheers,<br>
Martin<br>
<br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
</div></div><a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a> [4]<br>
</blockquote>
<br><span class=""><font color="#888888">
--<br>
Jasper<br>
<br>
<br>
Links:<br>
------<br>
[1]<br>
<a href="https://www.mail-archive.com/Wayland-devel@lists.freedesktop.org/msg12261.html" target="_blank">https://www.mail-archive.com/<u></u>Wayland-devel@lists.<u></u>freedesktop.org/msg12261.html</a><br>
[2] <a href="http://www.nsa.gov/research/_files/selinux/papers/module/x45.shtml" target="_blank">http://www.nsa.gov/research/_<u></u>files/selinux/papers/module/<u></u>x45.shtml</a><br>
[3] <a href="http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html" target="_blank">http://www.x.org/releases/<u></u>X11R7.5/doc/security/XACE-<u></u>Spec.html</a><br>
[4] <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a></font></span><div class=""><br>
<br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></blockquote><div class=""><div class="h5">
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Jasper<br>
</div></div>