On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick < [email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
