Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Martin Peres <martin.peres-GANU6spQydw <at> public.gmane.org>
Subject: Re: Summary of the security discussions around Wayland and privileged clients
Newsgroups: gmane.comp.freedesktop.wayland.devel
Date: Wednesday 26th February 2014 21:40:16 UTC (over 3 years ago)
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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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
 
CD: 4ms