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?
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/[email protected]/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/[email protected]/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
