Google Summer of Code 2018
Hi everyone, Just a quick word to remind you that the X.Org Foundation got accepted to the Google Summer of Code 2018! As a potential mentor, if you have a project falling under the foundation's (large) umbrella that you would like to kick start or get help finishing, please add it to the list on the ideas page[1] as soon as possible. Students will start applying on the 12th of March, see the full timeline[2]. As a student, check out the projects our ideas' page[1]. If you find one that interests you, check out our application guidelines[3] and, if you are eligible, contact your potential mentor and start discussing right away with him/her. We welcome any student who finds the prospect of working on our Open Source Graphics stack exciting! I will be once again the primary contact for the X.Org Foundation, so please ask me anything by email or on IRC (mupuf on freenode). Other administrators are Alex Deucher and Taylor Campbell (both Cc:ed). Looking forward to interacting with old and new contributors, and maybe welcome previous GSoC/EVoC students as mentors now that they grew to become core contributors and/or have full-time jobs in the Graphics stack (*wink wink nudge nudge*)! Martin, on behalf of the X.Org Foundation [1] https://www.x.org/wiki/SummerOfCodeIdeas/ [2] https://developers.google.com/open-source/gsoc/timeline [3] https://www.x.org/wiki/GSoCApplication/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC 2017 : Call for paper
Hello, I have the pleasure to announce that the X.org Developer Conference 2017 will be held in Mountain View, California from September 20th to September 22nd. The venue is located at the Googleplex. The official page for the event is http://www.x.org/wiki/Events/XDC2017 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2017/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Given that the conference is located at Google, we would welcome topics related to Android and Chromebooks. We would also like to hear about Virtual Reality and end-to-end buffer format negociation. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and open to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering, so if you are attending please add your name as early as possible. I am looking forward to seeing you there. If you have any inquiries/questions, please send them to Stéphane Marchesin (please also CC: board at foundation.x.org). Martin Peres ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] Requests for Proposal for hosting XDC 2018
On 12/05/17 02:46, Manasi Navare wrote: > Hi Daniel, > > Is Call for Papers opened yet for XDC? When do they usually start accepting > proposals? Hey Manasi, Our call for paper is usually sent around June with a deadline for mid-August. Here is the call for paper from last year, we do expect it to change: https://www.x.org/wiki/Other/Press/CFP2016/ Hope that helps :) Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] gestures: reduce the 2fg scroll timeout to 150ms
On 03/08/16 12:36, Peter Hutterer wrote: This timeout is there to switch to scrolling when the fingers rest on the touchpad unmoving and thus avoids the initial scroll threshold for slow scrolls. Since the only other gestures we support are swipe (usually a fast movement) and pinch-and-rotate (also a fast movement) we can drop the timeout down significantly and thus make the scroll feel more reactive. https://bugs.freedesktop.org/show_bug.cgi?id=93504 Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad-gestures.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c index acfc875..c965e11 100644 --- a/src/evdev-mt-touchpad-gestures.c +++ b/src/evdev-mt-touchpad-gestures.c @@ -30,7 +30,7 @@ #include "evdev-mt-touchpad.h" #define DEFAULT_GESTURE_SWITCH_TIMEOUT ms2us(100) -#define DEFAULT_GESTURE_2FG_SCROLL_TIMEOUT ms2us(500) +#define DEFAULT_GESTURE_2FG_SCROLL_TIMEOUT ms2us(200) Is it 200 or 150 you want? There is a mismatch with the commit title :) static inline const char* gesture_state_to_str(enum tp_gesture_state state) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDC 2016 : Call for paper
On 13/05/16 01:56, Martin Peres wrote: Hello, I have the pleasure to announce that the X.org Developer Conference 2016 will be held in Helsinki from September 21 to September 23. The venue is located at Haaga-Helia university[0], next to the Pasila station. The official page for the event is http://www.x.org/wiki/Events/XDC2016 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2016/ Friendly reminder that the deadline for the abstracts is in about a month (August 17th). Please also remember to register for the conference by adding yourself to the attendees list[1] or asking me to do it. See you there! Martin [1] http://www.x.org/wiki/Events/XDC2016 As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and opened to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering, so if you are attending please add your name as early as possible. I am looking forward to seeing you there, if you have any inquiries/questions, please send them to me (please also CC: board at foundation.x.org). Martin Peres [0] https://www.google.fi/maps/place/Ratapihantie+13,+00520+Helsinki/@60.2013725,24.931852,17z/data=!3m1!4b1!4m5!3m4!1s0x469209921fdba137:0x841c90a2862185af!8m2!3d60.2013725!4d24.9340407 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Introduction and updates from NVIDIA
On 13/06/16 12:32, Martin Peres wrote: This discussion has been going on for years (not this thread, the general discussion). Pekka made me realize on IRC that I was not specific enough about what I mean here. By discussion here, I am talking about sharing buffers across blocks/drivers/manufacturers while honouring Wayland's mantra of every frame being perfect and being as efficient as possible. This is related to Google's GRalloc, GBM, EGLStreams and probably more. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Introduction and updates from NVIDIA
On 21/03/16 18:28, Miguel Angel Vico wrote: Hi all, First of all, I'd like to introduce myself to the Wayland community: My name is Miguel A. Vico, and I've been working as a Software Engineer for NVIDIA for some time now, more specifically, in the Linux drivers team. Although I've never spoken before, I've been lately following the amazing work that you all have been doing here. We have been working on adding to our drivers all required features to be able to run Wayland and Weston on top of it. We have just released our NVIDIA's 364.12 GPU driver, which brings initial DRM KMS support (among other things). Please, check out our public announcement here: https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/ In order to make the Weston DRM compositor work with our drivers, we have used EGLDevice, EGLOutput, and EGLStream objects. Hi everyone, This discussion has been going on for years (not this thread, the general discussion). This issue is hindering Wayland and X, as mesa developers cannot enable HW features such as compression or new tiling modes for scanout buffers and we need to create one standard that would work also for AMD, NVIDIA and ARM platforms. How about we actually have a forum/track at XDC just for these issues and we do not go out of the room/conference without a plan? This is after all the raison d'être of XDC, making it less difficult for developers to talk with each others! During this session, I would like to have all the goals and requirements put out in clear lists, then we can work on defining the priorities and then try to create the least amount of protocols to address as many problems as possible at the same time. Of course, all the interested parties should be coming to XDC2016 (Helsinki, 2016-09-21 -> 23). Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC 2016 : Call for paper
Hello, I have the pleasure to announce that the X.org Developer Conference 2016 will be held in Helsinki from September 21 to September 23. The venue is located at Haaga-Helia university[0], next to the Pasila station. The official page for the event is http://www.x.org/wiki/Events/XDC2016 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2016/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and opened to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering, so if you are attending please add your name as early as possible. I am looking forward to seeing you there, if you have any inquiries/questions, please send them to me (please also CC: board at foundation.x.org). Martin Peres [0] https://www.google.fi/maps/place/Ratapihantie+13,+00520+Helsinki/@60.2013725,24.931852,17z/data=!3m1!4b1!4m5!3m4!1s0x469209921fdba137:0x841c90a2862185af!8m2!3d60.2013725!4d24.9340407 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 30/03/16 09:33, Jasper St. Pierre wrote: I really hope that distributions don't see security policies as a differentiator. This is how we got SELinux vs. AppArmor and real-world apps having to ship both kinds of policies (or Fedora flat out ignoring any idea of third-parties and such and including literally every application ever in its contrib policy file https://github.com/fedora-selinux/selinux-policy/tree/f23-contrib). I would also *hate* that. I hate distros that do not ship software as vanilla as possible :s However, what may save us here is that the policy is very high-level and it should be quite hard to differentiate! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 30/03/16 01:12, Olav Vitters wrote: On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote: We thus wanted to let distros take care of most of the policies (which does not amount to much and will likely come with the application anyway). However, some distros or devices come with a system that already defines security policies and they will likely not want a proliferation of storage places. Hence why we allowed for multiple backends. But this is an exception rather than the rule. Why should every distribution decide on some policy? The default way should work sanely and the way that a user would experience it makes sense. I help out with Mageia (+GNOME), I'm 98% sure Mageia has 0 interest in creating/developing such a policy. In WSM, you can set default behaviours for interfaces. This should cover your use case. However, remember this: If it is not the user or the distribution, then you are basically trusting the developer of the application... which basically means we are back to the security of X11. e.g. Linus complaining about (IIRC) needing to provide a root password after plugging in a printer. If we create such a situation again I might even understand why he's rants :-P This would be utterly ridiculous, and this is what we addressed here: http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 28/03/16 23:47, Drew DeVault wrote: On 2016-03-28 10:50 PM, Martin Peres wrote: Client->Server: What features do you support? Server->Client: These privledged features are available. Client->Server: I want this feature (nonblocking) [compositor prompts user to agree] Server->Client: Yes/no [compositor enables the use of those protocols for this client] That looks like the bind operation to me. Why do you need a new protocol? How do you propose clients would communicate their intentions to compositors? I may be misunderstanding. I was proposing for applications to just bind the interface and see if it works or not. But Giulio's proposal makes sense because it could be used to both grant and revoke rights on the fly. So, you are OK with being asked *every time* if you accept that VLC is trying to go fullscreen? I most definitely am not :D No, the compositor can remember your choice. So, you would be asking users to click on "I agree" and "remember my choice" every time they set up a computer then :D Not nearly as bad, but still bad. (following what chrome and firefox are doing is likely a good idea). I agree, permission management on Firefox is good. Right, we should really aim for something similar, UX-wise. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 28/03/16 16:04, Drew DeVault wrote: On 2016-03-28 9:08 AM, Giulio Camuffo wrote: On this, see https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html I have not been able to continue on that, but if you want to feel free to grab that proposal. I looked through this protocol and it seems like it's a good start. We should base our work on this. Being able to send accept/deny messages to the clients asynchronously really will be needed for making good UIs. We need to be able to revoke rights and add them on the fly. Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 28/03/16 16:03, Drew DeVault wrote: On 2016-03-27 10:21 PM, Jasper St. Pierre wrote: I would rather the effort be spent making secure interfaces, exactly as you've described. Agreed. I think it should be pretty straightforward: Client->Server: What features do you support? Server->Client: These privledged features are available. Client->Server: I want this feature (nonblocking) [compositor prompts user to agree] Server->Client: Yes/no [compositor enables the use of those protocols for this client] That looks like the bind operation to me. Why do you need a new protocol? I can start to write up some XML to describe this formally. We can take some inspiration from the pointer-constraints protocol and I'll also rewrite that protocol with this model in mind. Does anyone see anything missing from this exchange? So, you are OK with being asked *every time* if you accept that VLC is trying to go fullscreen? I most definitely am not :D This is why we wanted to let distro devs decide for their users what the default policy should be. We then need to have a good UI for users to realize that the application is running in fullscreen mode (following what chrome and firefox are doing is likely a good idea). However, Jasper has a point that we need to be sure that we can override the policy in a consistent way across all backends. I have a plan for this. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 28/03/16 02:41, Jasper St. Pierre wrote: You're probably referring to my response when you say "GNOME does not care about cross-platform apps doing privileged operations". My response wasn't meant to be speaking on behalf of GNOME. These are my opinions and mine alone. I must have mis-remembered then. Sorry. My opinion is still as follows: having seen how SELinux and PAM work out in practice, I'm skeptical of any "Security Module" which implements policy. The "module" part of it rarely happens, since people simply gravitate towards a standard policy. What's interesting to me isn't a piece of code that allows or rejects operations, it's the resulting UI *around* those operations and managing them, since that's really, at the end of the day, all the user cares about. The UI is definitely the most important part of this work. I think we gave already many ideas for the UI part in [1]. As much as possible, we want to avoid having the traditional ACL-style because not only is it not easy to discover and tweak but it is also going in the way of users. Instead, we would like to be as unintrusive as possible. We thus wanted to let distros take care of most of the policies (which does not amount to much and will likely come with the application anyway). However, some distros or devices come with a system that already defines security policies and they will likely not want a proliferation of storage places. Hence why we allowed for multiple backends. But this is an exception rather than the rule. What we envisioned was that when an app is using a privileged interface, there would be a new icon in the notification area telling which app is using what priviledged interface. Also, when right clicking on a running window, there would be a "capabilities" entry which, when clicked, would show on top of the application what are the current capabilities allowed and what is not. There, the user would be able to change the policy and have multiple options for each capability: - Default: (soft/hard allow/deny) - One time granting (until the app is closed) - One time revoke (revoke the rights immediatly) It would be a significant failure to me if we didn't have a standard way for a user to examine or recall the policy of an application, using whatever API they wanted. If every module implements its own policy store separately, such a UI would be extremely difficult to build. Yes, you are most definitely right. We only provided a default policy, but we also need a way to get feedback from the user about his/her preferences. One thing that is going to get problematic is what happens when one updates a piece of software and the policy does not match anymore. Since it is a pretty coarse grained policy, it should not be an issue! In any case, the user preference could be stored and managed by libwsm and modules would only be called if no user preference is found. From what I read, Wayland Security Modules didn't seem to even provide that as a baseline, which is why I believe they're tackling the problem from the wrong angle. We attacked the problem from a UX point of view and then a distro point of view. The custom configuration was a bit left on the side since experimented users could write their own file and more novice users would likely be more than OK with a runtime GUI to manage the rights and allow granting privileges when needed. We most definitely do not wish to ever have something as annoying as the UAC in Linux, constantly asking the user for permissions on things the user has no understanding about. I really think that the 4 levels proposed by libwsm make a lot of sense to reduce annoyance as much as possible [2] [1] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/ [2] https://github.com/mupuf/libwsm ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Collaboration on standard Wayland protocol extensions
On 27/03/16 23:34, Drew DeVault wrote: Greetings! I am the maintainer of the Sway Wayland compositor. http://swaywm.org It's almost the Year of Wayland on the Desktop(tm), and I have reached out to each of the projects this message is addressed to (GNOME, Kwin, and wayland-devel) to collaborate on some shared protocol extensions for doing a handful of common tasks such as display configuration and taking screenshots. Life will be much easier for projects like ffmpeg and imagemagick if they don't have to implement compositor-specific code for capturing the screen! I want to start by establishing the requirements for these protocols. Broadly speaking, I am looking to create protocols for the following use-cases: - Screen capture - Output configuration - More detailed surface roles (should it be floating, is it a modal, does it want to draw its own decorations, etc) - Input device configuration I think that these are the core protocols necessary for cross-compositor compatability and to support most existing tools for X11 like ffmpeg. Considering the security goals of Wayland, it will also likely be necessary to implement some kind of protocol for requesting and granting sensitive permissions to clients. How does this list look? What sorts of concerns do you guys have with respect to what features each protocol needs to support? Have I missed any major protocols that we'll have to work on? Once we have a good list of requirements I'll start writing some XML. -- Drew DeVault We had discussions about it years ago and here are the results of them: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/ And here is the software we created, under the name "Wayland Security Modules": http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf https://github.com/mupuf/libwsm This approach has generally be liked by KDE, but not by Gnome who, last i heard, did not care about cross-platform apps doing privileged operations. This may have changed since they also decided to work on sandboxing (xdg-app) and implemented something like the following approach when they said they would never do because it changed the API: http://mupuf.org/blog/2014/05/14/introducing-sandbox-utils-0-6-1/ I really wish we can have everyone onboard on one solution to get these cross-platform apps and so far, I do not see any better solution than WSM. Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC2015 - Travel sponsorship
Hello everyone, We are 1.5 months away from XDC and 20 days away from the proposals deadline[1]! If you did not manage to secure funding from your company but still think you could benefit the community by giving a talk, we encourage you to send an email to the board of X.Org with your talk proposal and we will review it in a timely fashion. Looking forward to seeing a lot of you soon, in Toronto! Martin, on behalf of the board of directors of X.Org [1] http://www.x.org/wiki/Other/Press/CFP2015/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
GSoC 2015: The X.Org Foundation has been accepted as a mentoring organisation
Hello, I have the pleasure to announce you that the X.Org Foundation has been accepted as a mentoring organisation for the Google Summer of Code 2015. This means that your project can receive students again this year! Here are the important dates coming[0]: - 16 March: Student application period opens. - 27 March: Student application deadline. - 24 April: All mentors must be signed up and all student proposals matched with a mentor - 27 April: Accepted student proposals announced on the Google Summer of Code 2015 site Potential mentors: Please put up your project ideas on our ideas page[1] by the end of the week to get the maximum chance of finding the best student possible. In any case, you are required to put your project up before March 16th. Students: Consult our ideas page[1] or come up with your own project idea. In any case, apply as soon as possible, take contact with potential mentors and ask them for advices on how to improve your chances of being accepted. This year, we are going to be a bit stricter than usual when it comes to selecting students. You thus have until April 23rd to get a patch accepted upstream to show us you can work in the open source community and with the usual tools (git, gcc, autotools, cmake, ...). An idea could be for you to pick a simple bug from the project's bugzilla and fix it. If you already have submitted patches to your project of choice or a closely-related project, you do not have to do anything. We however would still advice you to show your interest by providing patches or participating to our discussions. Finally, I would like to thank Google again this year for giving us the opportunity to get new blood to the projects under the X.Org Foundation's umbrella! Martin Peres, on behalf of the board of directors [0] https://www.google-melange.com/gsoc/events/google/gsoc2015 [1] http://www.x.org/wiki/SummerOfCodeIdeas/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDC2014: Call for paper
Le 02/05/2014 00:52, Martin Peres a écrit : Hello, I have the pleasure to announce that the X.org Developer Conference 2014 will be held in Bordeaux, France from October 8th to October 10th. The venue is located in the campus of the University of Bordeaux 1, in the computer science research lab called LaBRI. The official page for the event is http://www.x.org/wiki/Events/XDC2014 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2014/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and opened to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering. I am looking forward to seeing you there, if you have any inquiries/questions, please send them to me (please also CC: bo...@foundation.x.org). Martin Peres Two days left for submitting your talk proposal for the XDC2014. After this date, the remaining slots will be attributed on a first-come, first-served basis. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[XDC2014] Travel sponsorship
Hi everyone, If you are willing to give a talk at XDC2014 and require travel sponsorship, please send an email to bo...@foundation.x.org (CC: martin.pe...@free.fr) with an estimate of the travel + accommodation cost and the abstract of your talk. Please send us your applications as soon as possible and do so no later than September 5th! Thanks, Martin Peres - On behalf of the board of directors ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
Le 04/07/2014 09:58, Pekka Paalanen a écrit : On Thu, 3 Jul 2014 22:38:34 +0200 Fabrice Rey wrote: Hi all, This topic came up in my previous one about window placement, and I'd like to go further. So currently there is no such thing as Global shortkeys and keyboard focus, Have you tried searching for the wayland-devel mailing list archives for hotkeys/shortcuts? I think there was a pretty decent plan, IIRC based on a conference presentation on something about security and global hotkeys, where clients register or subscribe to actions and compositors map global keys to them or such. We just haven't heard from it on the list since. You have a good memory Pekka! You are referring to [0]. Peter Hutterer proposed a semantic approach to global shortcuts which could partially address the issue. I have not addressed the issue of global shortcuts in my blog article about how to handle privileged clients [1] mostly because I haven't made up my mind with it just yet. However, I was looking into a KDE-like solution where a compositor-exported application centralizes the global shortcuts. Any application running could listen to semantic events such as "play/pause". Applications may register new semantic actions. In this case, application would request to add a semantic action + a default shortcut for it. The compositor would then prompt the user to ask if the application is allowed to add a semantic event with the default shortcut proposed by the application. If no conflict exist, the user could press "Add the shortcut", "Cancel", "Customize the shortcut". If a conflict exists, only the last two would be allowed. If the user presses the "Customize the shortcut" button, the compositor would launch the global keyboard center to let the user add the shortcut he/she wants. If the user wants to update the shortcuts, the application should send a request for the compositor to launch the shortcut application (this should be part of a semantic way of launching applications, like: launch the default camera application, or launch the calculator). Some applications may actually want to be launched at a particular event (run kcalc when pressing the "CALC" button on the keyboard). For those, I'm not sure if the package manager should ask the compositor to add the shortcut or add a file containing the new shortcuts defined and their definition. In the latter case, the shortcut manager could detect the added file and if there is a conflict, ask the user to deal with it. These are my current thoughts on the matter, I would love to hear from what you would like to have but as Steve said, I'm very busy at the moment as I am writing my PhD thesis :s Cheers, Martin [0] https://www.youtube.com/watch?v=hJpiJii44oo&list=UUYhzLcUuRRyyhPqGxqr9E3A#t=2102 [1] http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC2014: Call for paper
Hello, I have the pleasure to announce that the X.org Developer Conference 2014 will be held in Bordeaux, France from October 8th to October 10th. The venue is located in the campus of the University of Bordeaux 1, in the computer science research lab called LaBRI. The official page for the event is http://www.x.org/wiki/Events/XDC2014 while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2014/ As usual, we are open to talks across the layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. If you're not sure if something might fit, mail me or add it to the ideas list found in the program page. The conference is free of charge and opened to the general public. If you plan on coming, please add yourself to the attendees list. We'll use this list to make badges and plan for the catering. I am looking forward to seeing you there, if you have any inquiries/questions, please send them to me (please also CC: bo...@foundation.x.org). Martin Peres ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
On 27/02/2014 18:01, Jasper St. Pierre wrote: On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick mailto:sebast...@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. I think the policy should be compositor-agnostic, especially since some may run multiple compositors at the same time. We thus need to abstract the different compositors and I think that's the role of libwsm. Just like LSM (Linux Security Module), libwsm is just a collection of hooks that get called with a well-defined semantic, most-likely mostly based on the Wayland protocol rather than the internal implementation of the compositor. Libwsm would indeed ship with a default policy that doesn't depend on anything else than POSIX but it could be replaced very easily to use any security decision engine, may it be SELinux or whatever new and shiny decision engine appears in the future. The way I intend to do that is by having libwsm forward the hooks to the right security backend. A security backend would be a dynamically loaded .so by libwsm. libwsm will know which .so should be loaded by reading its configuration file. I already implemented such a system in PPassKeeper[1]. Just to make it clear, if no such abstraction is made, then all compositors will require changes when a new decision engine becomes available. But the worst problem is that each compositor will have different hook points with different semantics and this will require to write a different policy for each and every compositor. If I may say, I think it sucks hard ;) Your pluggable WSM just made the user unhappy. You're killing the messenger, not the problem ;). In this case, the problem would be the policy. WSM isn't PAM, I think having WSM only load ONE security backend is just easier and simpler. Cheers, Martin [1] http://www.mupuf.org/project/ppasskeeper.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
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) (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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
The X.Org Foundation is an accepted for the GSoC 2014!
Hey, open source graphics enthusiasts, Yesterday, Google announced that the X.Org foundation is an accepted organization for the GSoC 2014! If you are a potential mentor and would have a project you would like a student to work on, you can propose a project in the summer of code ideas wiki page[1]. Right now, we have 16 projects ideas, half of them being related to Xpra. If you are a student and are interested in a project covered by the X.Org Foundation (DRI, mesa, X-Server, Wayland and 2D/3D/video accel), you can send your project proposal to Google[2]. Bonus points if you find a mentor yourself. You can also have a look at the summer of code ideas wiki page[1] for interesting projects. Looking forward to seeing which projects will happen for this 2014 edition! Martin Peres [1] http://www.x.org/wiki/SummerOfCodeIdeas/ [2] https://www.google-melange.com/gsoc/homepage/google/gsoc2014 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Le 20/02/2014 21:26, Thiago Macieira a écrit : Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu: Le 20/02/2014 18:42, Thiago Macieira a écrit : Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor number. Is that the case? In that case, how should the privileged process clear the environment to allow child processes to be launched? Yes, it takes an FD as a parameter (http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_d isplay_connect.xml#63). The environment must be cleared automatically by the kernel because weston must be very careful about opening resources with O_CLOEXEC. I don't think you've understood my question. Suppose Weston is careful already. It creates the socket, ensures it's no O_CLOEXEC, sets WAYLAND_SOCKET and launches the privileged process. Now, the privileged process wants to launch a sub-process. How will the sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains a file descriptor number that isn't available to the child process. Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using fcntl() to set the socket's fd to CLOEXEC? It is true that multiple process could end up with the same connection and I didn't think about that. The problem is the same if an application connects to the compositor by itself and then forks. Not sure how the compositor could detect that :s ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Le 20/02/2014 20:43, Sebastian Wick a écrit : Am 2014-02-20 20:02, schrieb Martin Peres: Le 20/02/2014 13:04, Pekka Paalanen a écrit : snip It can be done, but with a little more effort than implied here. Binding to an interace means wl_registry.bind request, and failing that is always a fatal error, which terminates the client connection. All errors in Wayland are fatal like that. Instead, the interface should be always bindable, but include explicit protocol to indicate failure in using its requests. In this case, we can make something pretty simple, send a signal to the application if rights to use this interface has been granted. If the application tries to use the interface without having the rights to do so, an EPERM signal can be sent (not to be confused with the revokation signal that happens when rights have been revoked). What do you think? I would like to have a request_permission and a revoke_permission method and respectively a permission_granted and a permission_revoked event. An application might not need to permission or only needs it for a small amount of time. Yeah, seems good. Slightly unrelated: We also need a way for a program to ask the compositor to start a client (and we have to ask ourselves how to handle arguments, environment variables etc.). I was thinking about having a semantical approach to that. Something like "Open the preferred screenshot app" or "Open the preferred screen video capture app". The preferred apps would be configured by the user (with default settings from the DE) and could include parameters passing, but I'm not sure it will happen. Is that something that would satisfy you? If you really want something generic, then isn't that something systemd could handle for us? I'm not really sure what you want to achieve here. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Le 20/02/2014 13:04, Pekka Paalanen a écrit : On Wed, 19 Feb 2014 17:11:03 +0100 Martin Peres wrote: Hi Guys, Following to the giant and impossible to read "Authorized clients" thread, I said I would take the time and write everything we talked about down, for convenience and to check I took everyone's idea and needs into account. I published the whole article on my blog [1] but I also wanted to copy the relevant information in this email, so as it could be easier for people to comment inline (since I'm really interested in feedback here), sorry for the markdown syntax but that's what I use for my website. I added Martin Graesslin in CC because he has shown interest in this and I'm sure his experience can benefit all of us. Hope something close to this proposal will be satisfactory to everyone and work can begin in this direction! Cheers, Martin Peres [1] http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ Nice work! :-) Thanks, the write up did take some time. However, it's not technically my work since at least 7 people have been discussing about this. I merely compiled the ideas as best as I could. Recommendations to restricted Wayland interface designers I have never designed an interface for Wayland and don't know what the best practice is. However, I know that restricted interfaces should never be considered as always usable. The first important point is that before being able to use an interface, a client should first bind to it. This binding process could either succeed or fail, depending on the compositor's security policy. Clients are mandated to test that binding worked well before using the interface. In case it didn't, clients should fail gracefully and tell the user what restricted interface couldn't be bound. Also, binding a restricted interface could take some time and the application shouldn't block on it. It can be done, but with a little more effort than implied here. Binding to an interace means wl_registry.bind request, and failing that is always a fatal error, which terminates the client connection. All errors in Wayland are fatal like that. Instead, the interface should be always bindable, but include explicit protocol to indicate failure in using its requests. In this case, we can make something pretty simple, send a signal to the application if rights to use this interface has been granted. If the application tries to use the interface without having the rights to do so, an EPERM signal can be sent (not to be confused with the revokation signal that happens when rights have been revoked). What do you think? To support privileges revocation, a revoke signal should be added to the interface in order to inform clients their rights to access the restricted interface have been revoked. Clients should fallback gracefully and tell the user they received such a signal. Launching privileged Wayland clients from the compositor The most-secure way of launching clients requiring restricted interfaces is to let the compositor run them by itself. This way, it can control the environment in which the process has been launched which lowers the risks of environment attacks such as the ``LD_PRELOAD`` one exposed earlier. Implementing such a system is difficult as the compositor needs to remember that the PID of the client it launched should be granted the privileges to access one or more restricted interfaces when this (soon-to-become)client connects to the Wayland compositor. Not only does it mean that the compositor needs to have a separate table of which PIDs are supposed to get which privileges, it also means the compositor needs to keep track of the death of the client's PID to avoid another process from re-using the PID of this client and gaining access to privileged interfaces it wasn't supposed to access. FWIW, Weston already does track its children by pid also, so that it can respawn them as needed if they e.g. crash. Oh, ok. But not all Wayland compositors want to support that. They certainly don't have to! A simpler and more secure solution would be for the compositor to open a UNIX socket to itself before exec'ing the client. Once opened, it should be simpler for the compositor to set the client's capabilities to a flag stored in the structure tracking the client and then execute the client's binary. When running the exec() syscall, all the FDs that have not been opened with the ``O_CLOEXEC`` [flag](http://linux.die.net/man/2/open) will be passed on to the new process. A run-time parameter of the Wayland client could then be used to tell which FD represents the unix socket to the Wayland compositor. An example of such parameter could be ``--wayland-fd=xxx``. The compositor should however be careful it doesn't leak any un-needed FD to the new client. Weston already implements this, and libwayland-client directly suppo
Re: Summary of the security discussions around Wayland and privileged clients
Le 20/02/2014 18:42, Thiago Macieira a écrit : Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor number. Is that the case? In that case, how should the privileged process clear the environment to allow child processes to be launched? Yes, it takes an FD as a parameter (http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_display_connect.xml#63). The environment must be cleared automatically by the kernel because weston must be very careful about opening resources with O_CLOEXEC. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Summary of the security discussions around Wayland and privileged clients
Hi Guys, Following to the giant and impossible to read "Authorized clients" thread, I said I would take the time and write everything we talked about down, for convenience and to check I took everyone's idea and needs into account. I published the whole article on my blog [1] but I also wanted to copy the relevant information in this email, so as it could be easier for people to comment inline (since I'm really interested in feedback here), sorry for the markdown syntax but that's what I use for my website. I added Martin Graesslin in CC because he has shown interest in this and I'm sure his experience can benefit all of us. Hope something close to this proposal will be satisfactory to everyone and work can begin in this direction! Cheers, Martin Peres [1] http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ -- Current state of security within Wayland compositors The first good point of the Wayland protocol is input management. At the moment, the protocol doesn't allow snooping on the input (confidentiality), generating input events (integrity) nor for an application to grab all events (availability). However, Wayland clients allowing ``LD_PRELOAD`` are still vulnerable to input attacks, as [demonstrated](https://github.com/MaartenBaert/Wayland-keylogger) by Maarten Baert. This is not Wayland compositors' problem so it won't be taken into account in this discussion. Just like with X, there are multiple ways for applications to send their output buffers to the graphics server. With Wayland/Weston, applications can use shared memory (SHM) or GEM's buffer sharing mechanism. SHM buffer sharing is meant for CPU-rendered application while GEM-based buffer sharing is meant for GPU-rendered applications. SHM buffer sharing seems to be using anonymous files and [file descriptor(fd) passing](http://keithp.com/blogs/fd-passing/) in order to transmit buffers from the client to the compositor. This makes sure that only the creator and the receiver of the fd can access the (now-shared) resource, making it impossible for a third-party other than the kernel to spy on or modify the output of other applications (confused-deputy). Confidentiality and integrity seems to be guaranteed but I haven't dwelved into the implementation to make sure of it. GEM buffer sharing [is known to be insecure](http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/) because shared buffers are referenced by a easily-guessable 32-bit handle. Once the handle is guessed, the buffer can be opened by other application run by the same user without access control. Once opened, the buffers may be read from or written into. This means confidentiality or integrity cannot be guaranteed on the output of applications using this buffer-sharing method. On-going work [is being performed](http://lists.freedesktop.org/archives/Wayland-devel/2014-January/012727.html) to make use of [DMA-Buf](https://www.kernel.org/doc/Documentation/dma-buf-sharing.txt) instead of GEM. DMA-Buf, just like SHM, is based on anonymous files and fd-passing and even allows different GPU drivers to exchange GPU buffers. Once the Wayland protocol and GPU applications start using it, confidentiality and integrity of the output buffers won't be a problem anymore. +-+-+--+ |Property | Input | Output | +-+-+--+ | Confidentiality | YES | WIP| |Integrity| YES | WIP| | Availability | YES | YES| +-+-+--+ The need for standardised privileged interfaces Although Tim and I advised Wayland compositors [not to rely on external programs](http://phd.mupuf.org/publication/2012/09/19/xdc2012_secu_recap/) to perform privileged tasks, some people do think it is needed as they want to make it possible to develop cross-compositors applications performing privileged tasks. Examples of such applications would be: - Screenshot applications (stills and video) - Virtual keyboards and pointing devices - Screen sharing (VPN, Skype) - Hotkeys handlers (?) - Session lockers All of these applications are violating one or more security properties. Wayland compositors should thus control the access to the interfaces allowing those applications to work. Since we want these applications to be cross-compositors, a standardised way of granting/passing/revoking privileges should be described in the protocol or its implementation reference guide. Allowing the user to securely break security properties By default, the system should be enforcing all the security properties we defined earlier. H
Fwd: [GSoC2014] Call for projects ideas and mentors
Re-send to include the wayland and mesa mailing lists. Sorry for the noise Original Message Subject:[GSoC2014] Call for projects ideas and mentors Date: Thu, 06 Feb 2014 01:03:05 +0100 From: Martin Peres To: dri-de...@lists.freedesktop.org , xorg-de...@lists.x.org, x...@lists.x.org, nouveau Hi, fellow graphics stack developers, Now that FOSDEM is over, it is time to think about the Google Summer of Code 2014! If you would like to propose a project for the GSoC 2014, please write your proposals at [1], before the 14th of February, in order to increase our chances of being an accepted organization. If you simply would potentially be interested in being a mentor, please also contact me as Google wants to have an estimate of the number of potential mentors we would have. If you have any questions regarding the GSoC or need any additional information, please answer in this thread. Cheers, Martin [1] http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Screen shooting and recording protocols (Re: Authorized clients)
Le 09/01/2014 22:14, Martin Peres a écrit : Le 09/01/2014 21:47, Maarten Baert a écrit : On 09/01/14 10:00, Pekka Paalanen wrote: Those are some reasons why screen recording (video) is easier to do as a compositor plugin, like it is currently in Weston. A separate client would need a non-trivial amount of new Wayland protocol to work well. That's probably true, but you can't expect applications to write a separate plugin for each compositor. Besides, I highly doubt that it's a good idea to load ffmpeg/libav and all its dependencies into the compositor - these libraries aren't exactly known for their stability ;). Very valid point! Instead, a client could ask the compositor to ask the user which window she wants to capture, and then the compositor would capture only that. Capturing individual outputs is a lot easier: Wayland core protocol already exposes all outputs, so the client can directly ask for a certain output. The window picking function that I have now (for X11) is really just a way to quickly enter the correct coordinates and size of the area that should be recorded. I don't expect the user to move the window around. And just to be clear, the goal is NOT to capture only the buffer of a single window, because then 'subwindows' (like browser plugins) and dialog windows won't be recorded. If I really wanted to capture just a single SHM buffer, I would probably just do it client-size, in the same way I already do OpenGL recording now (because this gives me much more flexibility). So what I'm asking for is just a function to get the rectangle (x,y,w,h) that corresponds to the window directly below a given position (x,y). The compositor doesn't even have to handle the complexity of 'real' user interaction (i.e. showing a message to the user telling him to pick a window, waiting for the user to do that, dealing with clients that make a request and then die, ...). Such a function would do everything I need, and I think it also covers what the existing screenshot applications need. I prefer to do it like this because it is the most simple way to implement this for the compositor, and it is more flexible (e.g. applications can choose to select the recording area in advance and then repeatedly use the same area without telling the user to select it over and over again). I'm not saying supporting the acquisition of just a rectangle isn't a good idea but if what the user wants is the output of a window, it is stupid to grab the whole screen. Shouldn't we try to make stuff just work, whatever the user does? In the part I cut out, there were some concerns about who and how should decide what hotkeys may or may not start shooting or recording. I think there was recently'ish a nice suggestion about a generic solution to the global hotkey problem, so you can probably leave it for that. I'm referring to the "clients bind to actions, server decides what hotkey is the action" kind of an idea, IIRC. There is a myriad of details to solve there, too. That would make a lot more sense, at least it is a lot more flexible than requiring the recording application to be launched by the same key press that starts the recording (which would effectively force me to split my application into two separate processes, and then I would have to figure out a secure way to let these two processes communicate). But what about things like mouse clicks? Can the compositor tell that the user clicked the 'start recording' button? It can't but we are talking about video recording. The app should just drop the frames when it is not interested in them. Once it has been run with the right hotkey, it will receive all the frames. As for security, the compositor should provide some feedback in the notification tray until the apps stops, I guess. This is exactly what I want to avoid: https://www.youtube.com/watch?v=s5D578JmHdU Chrome not properly revoking the rights to access the mic nor displaying its internal state properly. Static access control is not sufficient for that (the website got the permission from the user). Chromium should let the user express his intent that all sound recording should be stopped at this point. Privilege revocation is not handled properly and allowing the user to view the current state of the system is apparently not done properly. I should really take the time summarize what are the options we discussed, their associated risks and what should be done to mitigate them. Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Nominations for X.Org Foundation Board of Directors are OPEN
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2014 election are now open and will remain open until 23.59 GMT on 12 February 2013. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2013 were Alan Coopersmith, Martin Peres, Peter Hutterer and Stuart Kreitman. They will continue to serve until their term ends in 2015. Current directors whose term expires in 2014 are Matthias Hopf, Keith Packard, Matt Dew, and Alex Deucher. A director is expected to participate in the bi-weekly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23.59 GMT on 12 February 2014. The slate of candidates will be published 13 February 2014 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 18 February 2014. The Election Committee X.Org Foundation ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 10/01/2014 19:39, Jasper St. Pierre a écrit : On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres <mailto:martin.pe...@free.fr>> wrote: Le 10/01/2014 16:44, Maarten Baert a écrit : On 10/01/14 14:56, Martin Peres wrote: Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream. If by 'upstream' you mean the kernel: I don't think anything new is needed, actually. Create a separate directory in /run/user/1000 for each application, use cgroups to restrict applications to their own folder (assuming that's possible, I didn't check it). And who would manage the sandboxes? Systemd won't be able to because it is user applications. systemd and logind both support user-spawned applications. In fact, one of the goals for the 3.12 cycle of GNOME is to work on systemd user sessions. Sweet! I wonder how it will work. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 10/01/2014 19:37, Maarten Baert a écrit : On 10/01/14 18:13, Martin Peres wrote: And who would manage the sandboxes? Systemd won't be able to because it is user applications. I don't know how this will be done in the future, I can't predict that. I suppose there will be some kind of sandbox manager just like we have virtual machine managers today. I guess we'll need to educate users if we go this way. We need to do that anyway ;). LSM just defines hooks, not the decision engine. Or we create 'Wayland Security Modules' and provide a default module, which can then be replaced later if needed. That makes perfect sense and it was something we have been wondering since 2012 :) Okay, so why don't we do this? I realize that Sebastian Wick already suggested using PolKit for the same reason, but I think PolKit is already too specific. It wasn't really created with sandboxes in mind. PolKit is a good choice now but it may be replaced in the future, so compositors and applications shouldn't depend on it too much. Sure, and WSM (good name) can be linked to polkit or our own implementation of the policy afterwards. Yes, but those apps who really need it should be compiled with it. Almost all the other apps do not need this, especially not the ones we need to trust. Who cares about the confidentiality of games ;) As for OpenGL recording, you won't need that anymore, will you? Ideally, if we can get all compositors to implement a screen capturing protocol, and we extend it to 'window capturing' as well (more on that in the other thread), and they all implement it in a way that works well, then I won't need it anymore. But that will take time. The nice thing about my current OpenGL recording implementation is that it doesn't have to depend on anything. It can work with X11 or Wayland, GLX or EGL, OpenGL or OpenGL ES and it doesn't require one specific window manager. It also allows me to add my own rate control logic and other complex things to the application that is being recorded. For example, I can artificially reduce the game frame rate so it matches the frame rate I want (this isn't speculation, this feature actually exists and it works great for most games). So it's always nice to have it as an alternative, even though it isn't perfect. What if you missed it? libnotify can be added to make it more obvious, but a sticky icon should always be visible on screen. Yes, I think both should be used. Ok, great. We'll need to write a guide for compositors to follow in order to be secure. What you want is what Sebastian described: The compositor should ask the user if he agrees in the case where an app didn't get launched by the compositor. In this message, it should be doable to remind the user he can get around that message by setting the recording app to "the one he wants" and then press "combinaison of key". I would prefer that solution (I wouldn't even use the launch hotkey anymore, actually). I don't thing recording apps (or screenshot apps, or any other app that needs access to restricted APIs) should be treated as a special thing by the compositor. The compositor just knows that key X launches application Y with permissions Z. The user can use it for any application they want. I'm sure there will be many other use cases for this authentication API, such as accessibility apps. I agree but we really need to make sure compositors do implement exactly what we tell them to :) Because I foresee how they are going to be used. The user will never give consent or even understand the security implication. Sure, the app has to access the snapshots but let's lower the risks by requiring the user's input ourselves. Okay, if this can be done with a dialog that is easy to understand, that's fine. I just don't want to end up in a situation where I have to provide DE-specific instructions about how the user should go to their control panel and set up my application so it can be launched by a hotkey with additional permissions. If the user tries to launch the application the normal way (from the menu), and it doesn't work, then he/she should understand why that happened and how it can be changed. Yes, it will need to be explicit and short. The difference is that there will be 3/4 wayland compositors while there will be tens of screenshot apps. The screenshot apps will mostly be un-maintained and people will add features to fit their needs and screw their security (while we don't have a good sandboxing system). The screenshot apps most people use are part of their desktop environment. I don't think they are unmaintained, they just work so no-one sees any need to change it. But I assume that the GNOME/KDE/XFCE/LXDE developers do know what they are doing and wouldn't allow features that would compromise the security of their des
Re: Authorized clients
Le 10/01/2014 16:44, Maarten Baert a écrit : On 10/01/14 14:56, Martin Peres wrote: Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream. If by 'upstream' you mean the kernel: I don't think anything new is needed, actually. Create a separate directory in /run/user/1000 for each application, use cgroups to restrict applications to their own folder (assuming that's possible, I didn't check it). And who would manage the sandboxes? Systemd won't be able to because it is user applications. Until such sandboxing mechanism exists, what are we supposed to do then? Only install and run applications we trust, and hope that our decisions are correct. Sadly that's the best strategy we have right now. I guess we'll need to educate users if we go this way. That's a fair goal, indeed. That means you want to leave the authentication out of the protocol as much as possible so as you can plug whatever decision-making system you would want. That's kind of LSM for user applications. I hadn't heard of LSM actually, but I think it's exactly what we should do. LSM just defines hooks, not the decision engine. I am interested in this and also think this is the future. In the mean time, we should define a way that doesn't require any such system. Or we create 'Wayland Security Modules' and provide a default module, which can then be replaced later if needed. That makes perfect sense and it was something we have been wondering since 2012 :) This conflicts just like SELinux and DAC conflict. Ever heard of DAC override? We would just need the same system to be able to bypass the current authentication scheme if using a later system. Is that satisfying? Only if this can be done without changing every single client application. Let's say we go ahead and implement the system you proposed. This essentially forces all clients to launch themselves through the compositor, and register global bindings, and pass serials from those bindings in order to take a screenshot. That's already a huge nuisance for application developers, but let's ignore that. Now sandboxing appears, and all these old requirements make no sense with the new security model, in fact it makes things much harder because now the application, in its sandbox, will try to launch something through the compositor, outside that sandbox. The compositor now has to figure out how this sandboxing system works and put the newly launched application back in the same sandbox. Now the application tries to create a global binding, but are sandboxed applications even allowed to do that? There's a very real risk that requirements that make sense today will actually make things far worse in the future. It could take a decade. LD_PRELOAD would be much faster to get rid of in the mean time. ' There are valid use cases. Some debugging tools depend on it. OpenGL recording in my app depends on it. Even Steam depends on it for their 'community integration' system. It won't be removed any time soon ... Yes, but those apps who really need it should be compiled with it. Almost all the other apps do not need this, especially not the ones we need to trust. Who cares about the confidentiality of games ;) As for OpenGL recording, you won't need that anymore, will you? The reason I think it is important to avoid applications from not using the video feed directly is because of the notification needed for the user. If he runs the application then tries to quit it then he will wrongly assume he is out of the danger zone. If we mandate the application to start recording straight away, then the user could check if the notification (most likely a red record icon in the systray) is gone. If the application didn't really quit and starts recording later on, the user may not notice that the record notification appears. Then the notification should be more obvious! If the user doesn't notice that it appears, then he may also fail to notice that it /doesn't disappear/ when he closes the application. Even more so because human vision is very sensitive to changes but not very sensitive to things that stay the same. We already have a notification system that's universally accepted: libnotify. Just show a notification whenever that systray icon appears or disappears. What if you missed it? libnotify can be added to make it more obvious, but a sticky icon should always be visible on screen. However, now that I think of it, the notification could indicate an application has the rights to do the recording. This way, we don't waste ressources and the user still is able to tell if he is out of the danger zone. In this case, you should be able to start and stop the video recording. Sounds much better :). Just tell your users they need to select
Re: Authorized clients
Le 10/01/2014 04:32, Jasper St. Pierre a écrit : On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres <mailto:martin.pe...@free.fr>> wrote: On 09/01/2014 23:57, Maarten Baert wrote: On 09/01/14 21:54, Martin Peres wrote: The worse thing that can happen is an application running with the user's uid grabbing and sending periodical screenshots to a distant server running OCR and waiting for you to enter your bank details on amazon.com <http://amazon.com>. As for how this application got installed in the first plase, do I really have to list all the ways or can we both agree this is out of scope? Is that the worst case scenario you can come up with? :D Hey, don't twist his question and my answer ;) The question was IF our protocol is wrong. Remember, we aren't addressing the security of desktop here. We are looking for a way to provide a service (screenshots) and trying to find a way to make it as difficult as possible to misuse it. Right? My question was not meant to be taken in a vaccuum. In fact, quite the opposite. My question was about thinking whether it made sense to do access control at the Wayland level, or at the If not there, where? I am convinced userspace-exported services should do their own access-control and just refer to a central daemon to ask for permission. I already implemented something like that in PIGA-OS, it is called PIGA-SYSTRANS. Here, run this program. You can audit it, it won't steal your credentials, but it doesn't take a screenshot of the desktop, and is fairly convincing. It would probably even fool me. It's X11, simply because that's easier than writing a raw Wayland app at this point. It doesn't rely on any insecurities of X11. Build instructions are on top: https://gist.github.com/magcius/835501bc2728be83587f It was made in a hurry, so the main tell: the blinking cursor, I couldn't deal with. Somebody with more than an hour on their hands might be able to do something more with this concept. Nice one. I'm not sure it is doable in wayland right now to have an application in real full screen.We'll need to discuss how to handle that properly. As I said in the security presentation a friend of mine and I gave at XDC2012, full screen apps grabbing all keys are an availability hazard too. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 10/01/2014 03:27, Maarten Baert a écrit : On 10/01/14 01:05, Martin Peres wrote: Let me help: - The attacker has installed a Firefox plugin that sends him a copy of all forms that you fill out. - The attacker has messed with your PATH and has installed an infected Firefox binary in a folder you own, and you're running that instead of the real firefox, without realizing it. - The attacker has messed with your init files and you are actually in a chroot that he set up. - The attacker has created a virtual machine that looks just like your real computer, and he configured it to launch automatically, in fullscreen. Out of scope ;) That's hardly an answer. How do you want to create a secure desktop when you ignore valid issues because they are out of scope? Because we aren't trying to create a secure desktop. We are trying to design protocols that are hard to abuse. - The attacker has installed something like wayland-keylogger <https://github.com/MaartenBaert/wayland-keylogger> that sends him a list of all keys you pressed. No such thing possible. The wayland compositor gets the input from the kernel or from a virtual keyboard it launched itself. Then, it dispatchs the input to the right app, not any other app. We had been thinking about an app requesting all the keys as hot keys, but solutions have been found against that ;) ... What else do I have to do to convince you? I've created a proof of concept, I've given you the source code, I have tested it, IT WORKS, yet you still claim it is not possible?? Right, that was stupid of mine but again, just because something else is needed, we shouldn't bail out by just not caring about this. If one wants a secure desktop, he shouldn't compile applications with the possibility to use LD_PRELOAD. Or applications run from the DE should never be run the LD_PRELOAD environment variable. It should be quite easy to enforce that. Just because some (most?) users won't do it doesn't mean we shouldn't create a good interface. How can you even argue with that? - The attacker is watching /run/user/1000 with inotify so he can quickly open any files that appear there and if he is lucky, he gets access to some SHM buffers. - The attacker has renamed /run/user/1000/wayland-0 to something else and is running his own Wayland proxy that now listens on /run/user/1000/wayland-0. He uses this proxy to do a MITM attack on all Wayland applications. These two require MAC, we can't do anything about it. Anyway, this is again out of scope. We are talking about not abusing the feature we want to add! And all I'm saying is that the features you already have can already be abused, and that the fix for those issues will also fix the screenshot issue. So I think we should focus on that instead. Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream. If you can craft a VM that looks like the desktop of the person you are hacking ... without being able to get visual information for it, you are real good. It's doable because most people do very little customization. Take a standard Ubuntu desktop, figure out the desktop wallpaper (hardly a secret), figure out the pinned icons (also hardly a secret), and it will probably fool enough people to make it worthwhile. An attack doesn't require a high success rate when you can just target enough people. That's why those 'nigerian scams' work despite being totally obvious. Good points, but just because this attack is possible doesn't mean we should give up on the rest. This attack just isn't practical. Stop using fear mongering just so people wouldn't mind "a little more". You're obviously smart, so instead of denying the problem, we could work on it. That was never my intention - I am not trying to use fear mongering any more than you. But since we were discussing theoretical attacks, I figured it would be useful to mention a few other attacks too. I am not saying that the screenshot API should be freely accessible nor that it should be completely blocked. I am saying that it should be made secure as part of a much larger sandboxing mechanism, rather than reinventing the wheel and adding new security mechanisms. Until such sandboxing mechanism exists, what are we supposed to do then? You know, I actually implemented something like that with a research team, PIGA-OS. As nice as I think it is, you need to accept this is COMPLETELY out of the scope and has nothing to do with Wayland. Wayland should be as difficult to abuse as possible. Whatever MAC policy or system the future may hold, the protocol we'll be proposing should still be good! If you don't understand that, think about all the languages or protocols that sounded ok a while ago and how painful it is to get rid of them now to replace them with
Re: Authorized clients
Le 10/01/2014 02:37, Sebastian Wick a écrit : Am 2014-01-10 01:05, schrieb Martin Peres: Hey, don't twist his question and my answer ;) The question was IF our protocol is wrong. Remember, we aren't addressing the security of desktop here. We are looking for a way to provide a service (screenshots) and trying to find a way to make it as difficult as possible to misuse it. Right? With emphasis on "providing a service". You say that we should not provide the service which just won't work because some people need it. So instead of saying that we should not implement it would be better to find the most secure way to do this. I proposed 2 solutions already and I still think that they are as secure is it can get. You want that every use of a restricted protocol is the cause of an user action and I think it is: a) If you press a key-binding to launch a client which uses a restricted protocol you have a user action. I agree here, but you don't want to limit the number of screenshots the app can make? How, as a user, do you make sure the app you launched isn't running in the background? b) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and no matching configuration file can be found, the compositor requires the user to confirm or deny the request. That's obviously an user action, too. Seems good! c) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and a configuration file is found and the configuration says that the client DOES NOT require user input before using the protocol, the compositor requires the user to confirm the authorization. Again, user input. So you trust that the application will behave correctly. If that's something all of you agree on, then I guess I'll consider it good-enough since the program is run by the compositor... d) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and a configuration file is found and the configuration says that the client requires user input before using the protocol, the user has to use the program and click or press a key. Those events come from the kernel, go to the compositor and over a secure connection to the trusted client. This is no different from having a key-biding in the compositor. Even this case requires user input. just because a user clicks inside a window doesn't mean it the user meant to make a screenshot. If the application says "click here to win $100", the user has no idea that clicking will allow the application to make a screenshot. Without a UDAC-like system, the compositor has no way to know the semantic behind a click, so it won't work. This case should open a pop up like c). This is why I don't like this system, but I guess if you really want to allow applications to run a screenshot app, it does require a pop up and I don't find any way around it. This shouldn't be much of a problem because most users should use the "print screen" button anyway. You only have to trust that the client is not malicious like you also have to trust your compositor to not being malicious. If you don't want to trust the client then you obviously should not create a configuration in the trusted clients directory. Yes, I do agree but here is what I foresee: The configuration file to make your program work will be shipped by the distro, so it isn't really an input from the user to say "I agree with the security implication". Anyway, as much as I don't want that to happen, I guess it isn't wayland's problem anymore and that should be something the distro need to do. Then, in another mail you said: The only thing we disagree about it the "trusted" label. At first, you trust the app, but then, there is a new version that allows disabling the visual cues and settings are stored in a file owned by the user. Then an attacker simply has to change the settings, run the app in the background and get the images. So, as I said, I don't trust application developers for doing the right things! The whitelist for trusted applications must be only writable by root. That's why we don't want to mix it with the weston.ini configuration. Nobody said that we disable visual cues. The compositor knows which restricted protocols a client can access. You are free to implement a solution which shows it to the user in whatever form pleases you. I meant the application's visual cue that it is taking a screenshot, not the compositor's. Anyway, we agree on that, there is no need to discuss this I guess. You don't even have to trust application developers. The configuration file can be created by the packager of y
Re: Authorized clients
On 09/01/2014 23:33, Maarten Baert wrote: On 09/01/14 20:25, Bill Spitzak wrote: Screenshot applications I have seen are triggered by a key, yes, but all of them then show the initial screenshot to the user and then allow the user to change parameters and make a second screenshot. I suppose restricting the ui so that the user must hit the same key to trigger a second screenshot may work, but I am very worried about any scheme that forces ui decisions on clients. I fully agree with this. Usable and intuitive UI design is hard enough already without artificial limitations and requirements coming from the compositor ;). Martin Peres wrote: The video capture API concerns me more. I realize that many people will never use it, so I think it's okay to have it disabled by default and require that the user explicitly enables it (once!). But just because something /can/ be abused doesn't mean it should be banned completely. The feature is useful and needed, I'm not arguing with that. I don't like the idea of configuration because how do you make sure the configuration was set by the user and changed by a malicious app? Actually, I don't think this is needed. For video capture, the authentication could be white-list based and the application run using a hot-key. Do you think it is usable-enough? I certainly think this secure-enough for me as long as the compositor gives me an indication when the application stops recording that it indeed stopped and won't be able to start it again unless I want it to. However, I don't like the idea of having to audit the policy on every wayland computer I will be on especially since I'm pretty sure some devs won't mind if their application is a privacy killer. Uhm, you have to do that anyway. If you are using someone elses computer, you have already given up your security. This person may have recompiled his Wayland compositor. He may have added code to the Wayland compositor that captures every keystroke and emails it to him. He could even have installed a hardware keylogger in the keyboard you're going to use. If you don't trust the owner of a computer, you shouldn't use it for anything important, it's that simple. You can't seriously expect every single Wayland user in the world to comply with your security requirements just in case you may have to use their computer once, right? Because that's effectively what you are doing if you ban every possible protocol that could potentially be abused ... Yes, that was pretty stupid of me but the point remains, if you administrate multiple computers and some have video_capture/screenshot apps and some don't. You would need to remember which ones are which in order to know if you are safe or not? Can you guarantee apps will all require user input in order to operate? No offence, but I think you only think about your application. On 09/01/14 20:52, Martin Peres wrote: Yes, X11-style screenshot apps won't work but this is for a good reason, isn't it? And as far as I know, most users on Windows do not use any application for screenshots, they just press "print screen" and paste that in paint/whatever. 'Most users' is not good enough. A core system component like Wayland should aim to support the needs of as many users as possible, not just 'most users' ;). If you compare Windows and Linux, Linux is clearly good enough (or better) for 'most tasks'. And look where that got us ... I doubt the reason why Linux isn't used on every desktop is clearly not a technical reason. I'm sure you know that too, so please focus. With my proposed solution, the app would only be used to edit the screenshot (crop, resize). Different hot keys would be used depending on if you want to grab a window, a screen or all the screens. Is that that difficult onto users? Any other solution will result in lost confidentiality and, please, let wayland compositors be the only ones that cannot be spied on easily! [...] Users do not think them as being different because that's what they learnt. Should we keep on doing the same mistakes and carry than legacy thinking? Should we loose confidentiality just for the fringe amount of users who want a common GUI for screenshooters across all wayland compositors? You know my answer... Your requirements are too strict for many users. And whether you like it or not, the result will be that users disable these security features if they stop them from doing something. If Wayland lacks the ability to disable security features, some user will add them. If the patches are rejected upstream, there will be downstream patches or Wayland forks that do! I'm not saying that this is a good thing, I'm saying that it is unavoidable. This is an open-source project, it is impossible to ban a feature that users want. If
Re: Authorized clients
On 09/01/2014 22:16, Jasper St. Pierre wrote: On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres <mailto:martin.pe...@free.fr>> wrote: Le 09/01/2014 20:36, Jasper St. Pierre a écrit : Security is based on trust. If you trust nothing, the computer won't do very much for you. You can't even trust it to compute correctly. Security is based on access control. Every program that exposes a service should think about how can it be abused and should implement protocols as inherently-safe as possible. It should also implement mitigations when it is impossible to propose the service otherwise (an authentication system limiting the number of attempts per minute for instance). However, I do agree we need to trust the program that exports the service, of course ;) What's the threat model here? Let's say that we design a screenshot API, and in your opinion it's the worst thing ever. Who's attacking? How are they attacking? How will you mitigate it? Good, some methodology! I already answered it earlier but whatever :) Sorry, I must have missed it. It's a large thread. No probs. I understand. We'll need to make a recap email soon :) The worse thing that can happen is an application running with the user's uid grabbing and sending periodical screenshots to a distant server running OCR and waiting for you to enter your bank details on amazon.com <http://amazon.com>. As for how this application got installed in the first plase, do I really have to list all the ways or can we both agree this is out of scope? I feel it's out-of-scope from the point of view of Wayland. If there's an application on your computer that is trusted to handle screenshots, I don't believe it's the job of the Wayland compositor to second-guess it.t into Ask yourself, trusted by whom? You are partly right, the protocol should kind of be agnostic of the way the authentication works. On the other hand, I'm kind of leaning towards thinking the screenshot protocol almost shouldn't exist (the solution [1] I talked about before). However, we'll need a video capture protocol and I think we all agree on how to handle the authentication on this one because we just can't limit the number of captures :D It's not Wayland's problem if the NSA silently planted a malicious, trusted application on your computer. It's certainly dangerous that this could happen, paranoia doesn't make for a good user experience: imagine if your computer was a crazed conspiracy theorist :) The NSA may find a way, but when a script kiddy can do it, then there is obviously something wrong. So, unless you are the kind of guys who authenticate over the internet without SSL, then you need to revise your judgement on that ;) Who is attacking: - Someone interested in what you are doing (industrial espionage, justice department, government/NSA, spouse) - Someone interested in your credentials (bank account, company logins, etc...) - Fun? (Yeah, some people have nothing better to do with their lives). How are they attacking: Well, it depends on how (un)secure your system is. I cannot How do I mitigate this? The real solution would be not to have screenshots at all. However, we want to provide screenshots to the user if that's what he wants (responsibility on him though) so we need to make sure the user is indeed the one that is willing to get a screenshot. As we cannot trust applications, the server needs data to prove this is indeed the user who wants this screenshot. I see 3 possibilities here: - He/she pressed a key that is meant for that - He/she accepts that the app is trying to access the screenshot functionnality (pop up) - He/she disabled security until further notice or reboot (pekka's idea, no permanent setting) So how do we mitigate? By making sure no app is doing screenshots in the user's back. EVER (unless explicitly asked by him, but that should not be a permanent decision). In our threat model of sandboxed applications, which takes inspiration from Android, apps are given a coarse-grain set of permissions: this app can take screenshots. That app can access your contact list. These are guarantees that the user can see, and the system can provide. If the Flashlight app requires bluetooth, then something sketchy might be going on, and the user can "vote with their feet" and install a separate app. I'm a big fan of these permission-set. I see them as the only way for a user to know what is going on. The permission set is a contract that a user either accepts or refuses. However, and we need to be very clear abou
Re: Authorized clients
On 09/01/2014 23:57, Maarten Baert wrote: On 09/01/14 21:54, Martin Peres wrote: The worse thing that can happen is an application running with the user's uid grabbing and sending periodical screenshots to a distant server running OCR and waiting for you to enter your bank details on amazon.com. As for how this application got installed in the first plase, do I really have to list all the ways or can we both agree this is out of scope? Is that the worst case scenario you can come up with? :D Hey, don't twist his question and my answer ;) The question was IF our protocol is wrong. Remember, we aren't addressing the security of desktop here. We are looking for a way to provide a service (screenshots) and trying to find a way to make it as difficult as possible to misuse it. Right? Let me help: - The attacker has installed a Firefox plugin that sends him a copy of all forms that you fill out. - The attacker has messed with your PATH and has installed an infected Firefox binary in a folder you own, and you're running that instead of the real firefox, without realizing it. - The attacker has messed with your init files and you are actually in a chroot that he set up. - The attacker has created a virtual machine that looks just like your real computer, and he configured it to launch automatically, in fullscreen. Out of scope ;) - The attacker has installed something like wayland-keylogger <https://github.com/MaartenBaert/wayland-keylogger> that sends him a list of all keys you pressed. No such thing possible. The wayland compositor gets the input from the kernel or from a virtual keyboard it launched itself. Then, it dispatchs the input to the right app, not any other app. We had been thinking about an app requesting all the keys as hot keys, but solutions have been found against that ;) - The attacker is watching /run/user/1000 with inotify so he can quickly open any files that appear there and if he is lucky, he gets access to some SHM buffers. - The attacker has renamed /run/user/1000/wayland-0 to something else and is running his own Wayland proxy that now listens on /run/user/1000/wayland-0. He uses this proxy to do a MITM attack on all Wayland applications. These two require MAC, we can't do anything about it. Anyway, this is again out of scope. We are talking about not abusing the feature we want to add! All these can be done right now, no screenshot API needed ;). I'm sure I can come up with more attacks if I you give me some time. How do I mitigate this? Most of them can be stopped with Android-style sandboxing. The one with the VM relies on social engineering and is harder to avoid, but you could do what browsers do with fullscreen requests - show a big and obvious warning that the application is being displayed in fullscreen. Or by making the fullscreen interface restricted as well. The fullscreen interface is starting to look far more dangerous than the screenshot API, actually. If you can craft a VM that looks like the desktop of the person you are hacking ... without being able to get visual information for it, you are real good. This attack just isn't practical. Stop using fear mongering just so people wouldn't mind "a little more". You're obviously smart, so instead of denying the problem, we could work on it. I'm a big fan of these permission-set. I see them as the only way for a user to know what is going on. The permission set is a contract that a user either accepts or refuses. However, and we need to be very clear about this, no other application should be able to (ab)use the right of this application unless there is a direct consent of the user (and this is getting sketchy). And this is actually pretty easy once you have sandboxing. The screenshot program has access to the screenshot API and your files (because it needs to save the screenshot somewhere). The screenshot program allows fully automated screenshots, but they always end up in a fixed 'Screenshots' location (maybe ~/Pictures/Screenshots). Untrusted applications will obviously NOT get access to your files, because many of those files are likely private. Applications that aren't trusted will only get access to their own folder (maybe ~/.local/share/someapplication/). The attacker can trigger screenshots, but can't get the automated screenshots from the 'Screenshots' folder, and he can't force the user to save them to a folder that he has access to. Problem solved. You know, I actually implemented something like that with a research team, PIGA-OS. As nice as I think it is, you need to accept this is COMPLETELY out of the scope and has nothing to do with Wayland. Wayland should be as difficult to abuse as possible. Whatever MAC policy or system the future may hold, the protocol we'll be proposing should still be good! If you don't unders
Re: Screen shooting and recording protocols (Re: Authorized clients)
Le 09/01/2014 21:47, Maarten Baert a écrit : On 09/01/14 10:00, Pekka Paalanen wrote: Those are some reasons why screen recording (video) is easier to do as a compositor plugin, like it is currently in Weston. A separate client would need a non-trivial amount of new Wayland protocol to work well. That's probably true, but you can't expect applications to write a separate plugin for each compositor. Besides, I highly doubt that it's a good idea to load ffmpeg/libav and all its dependencies into the compositor - these libraries aren't exactly known for their stability ;). Very valid point! Instead, a client could ask the compositor to ask the user which window she wants to capture, and then the compositor would capture only that. Capturing individual outputs is a lot easier: Wayland core protocol already exposes all outputs, so the client can directly ask for a certain output. The window picking function that I have now (for X11) is really just a way to quickly enter the correct coordinates and size of the area that should be recorded. I don't expect the user to move the window around. And just to be clear, the goal is NOT to capture only the buffer of a single window, because then 'subwindows' (like browser plugins) and dialog windows won't be recorded. If I really wanted to capture just a single SHM buffer, I would probably just do it client-size, in the same way I already do OpenGL recording now (because this gives me much more flexibility). So what I'm asking for is just a function to get the rectangle (x,y,w,h) that corresponds to the window directly below a given position (x,y). The compositor doesn't even have to handle the complexity of 'real' user interaction (i.e. showing a message to the user telling him to pick a window, waiting for the user to do that, dealing with clients that make a request and then die, ...). Such a function would do everything I need, and I think it also covers what the existing screenshot applications need. I prefer to do it like this because it is the most simple way to implement this for the compositor, and it is more flexible (e.g. applications can choose to select the recording area in advance and then repeatedly use the same area without telling the user to select it over and over again). I'm not saying supporting the acquisition of just a rectangle isn't a good idea but if what the user wants is the output of a window, it is stupid to grab the whole screen. Shouldn't we try to make stuff just work, whatever the user does? In the part I cut out, there were some concerns about who and how should decide what hotkeys may or may not start shooting or recording. I think there was recently'ish a nice suggestion about a generic solution to the global hotkey problem, so you can probably leave it for that. I'm referring to the "clients bind to actions, server decides what hotkey is the action" kind of an idea, IIRC. There is a myriad of details to solve there, too. That would make a lot more sense, at least it is a lot more flexible than requiring the recording application to be launched by the same key press that starts the recording (which would effectively force me to split my application into two separate processes, and then I would have to figure out a secure way to let these two processes communicate). But what about things like mouse clicks? Can the compositor tell that the user clicked the 'start recording' button? It can't but we are talking about video recording. The app should just drop the frames when it is not interested in them. Once it has been run with the right hotkey, it will receive all the frames. As for security, the compositor should provide some feedback in the notification tray until the apps stops, I guess. Maarten Baert ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 09/01/2014 20:36, Jasper St. Pierre a écrit : Security is based on trust. If you trust nothing, the computer won't do very much for you. You can't even trust it to compute correctly. Security is based on access control. Every program that exposes a service should think about how can it be abused and should implement protocols as inherently-safe as possible. It should also implement mitigations when it is impossible to propose the service otherwise (an authentication system limiting the number of attempts per minute for instance). However, I do agree we need to trust the program that exports the service, of course ;) What's the threat model here? Let's say that we design a screenshot API, and in your opinion it's the worst thing ever. Who's attacking? How are they attacking? How will you mitigate it? Good, some methodology! I already answered it earlier but whatever :) The worse thing that can happen is an application running with the user's uid grabbing and sending periodical screenshots to a distant server running OCR and waiting for you to enter your bank details on amazon.com. As for how this application got installed in the first plase, do I really have to list all the ways or can we both agree this is out of scope? Who is attacking: - Someone interested in what you are doing (industrial espionage, justice department, government/NSA, spouse) - Someone interested in your credentials (bank account, company logins, etc...) - Fun? (Yeah, some people have nothing better to do with their lives). How are they attacking: Well, it depends on how (un)secure your system is. I cannot How do I mitigate this? The real solution would be not to have screenshots at all. However, we want to provide screenshots to the user if that's what he wants (responsibility on him though) so we need to make sure the user is indeed the one that is willing to get a screenshot. As we cannot trust applications, the server needs data to prove this is indeed the user who wants this screenshot. I see 3 possibilities here: - He/she pressed a key that is meant for that - He/she accepts that the app is trying to access the screenshot functionnality (pop up) - He/she disabled security until further notice or reboot (pekka's idea, no permanent setting) So how do we mitigate? By making sure no app is doing screenshots in the user's back. EVER (unless explicitly asked by him, but that should not be a permanent decision). In our threat model of sandboxed applications, which takes inspiration from Android, apps are given a coarse-grain set of permissions: this app can take screenshots. That app can access your contact list. These are guarantees that the user can see, and the system can provide. If the Flashlight app requires bluetooth, then something sketchy might be going on, and the user can "vote with their feet" and install a separate app. I'm a big fan of these permission-set. I see them as the only way for a user to know what is going on. The permission set is a contract that a user either accepts or refuses. However, and we need to be very clear about this, no other application should be able to (ab)use the right of this application unless there is a direct consent of the user (and this is getting sketchy). Locking down permissions UAC-style does not provide additional security. Again, when the user is accomplishing a task, and you give them a security prompt, you will get answers worse than random chance. The user is doing something, now they have to make a decision about yes/no. They are often ill-equipped to handle such questions. UAC is a piece of shit. Even as a security engineer, I cannot make a good decision because they just basically say "I need more privilege, do you agree?". Because users don't seem to care anymore, the little security benefit it could have renders the whole system useless. UAC is just proving that an MLS security policy ultimately resolves into running everything into the highest privileged mode. If they press a "Take Screenshot" button in the app, and the user is now prompted with a "Are you sure you meant to take a screenshot?" prompt, what happens if they hit No to get rid of the annoying prompt? What does the app do? What does the user do? What happens if the user hits no: Simple, you get no screenshot. When you visit a website with chrome and the website wants to know your location, you say yes or no. If the website cannot deal with it, it can't. From your previous email, you seem to be interested in UDAC. This is a paper I haven't taken the time to read yet, but if I'm right, it requires a way for applications to import "secure" widgets into their windows. In this case, there could indeed be a compositor-controlled "take screenshot" button and the application couldn't change it's meaning. While it is something that could eventually be done in Wayland using sub-surfaces, this is not doable right now so there is no
Re: Screen shooting and recording protocols (Re: Authorized clients)
Le 09/01/2014 20:14, Bill Spitzak a écrit : Pekka Paalanen wrote: Right... so that'd be a framerate hint, which the compositor only uses if it needs to do a significant amount of work for each sent frame. We probably want to keep most of the rate control still in the encoding program, so it can pick the best frames to drop or duplicate. My quick impression is that a framerate hint is not needed. Instead they are throttled by the client not releasing the buffers. If there is only one buffer not in use by the client the compositor cannot send the event. Depending on the implementation it can either keep updating this buffer with each frame, update it only once or periodically, or do nothing. When the client releases a second buffer it then waits if necessary for a frame to be copied to the buffer and then sends the event. That's a good idea, I didn't think to use the safety mechanism as a throttling one! There is one thing I don't like with this though. It will work great if the ring buffer only has 1 buffer. If it had more and we were using a method involving copies, it would create useless ones. It is good food for thoughts though! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 09/01/2014 20:25, Bill Spitzak a écrit : Martin Peres wrote: We don't need to trust the client much if we limit the number of screenshots to 1. This way, the worse thing that could happen for your privacy would be if your cat sits on the keyboard and presses "print screen" all the time while you key in sensitive information (unlikely, right?), even if the app just This is not true. The server can refuse to feed the application with more than one screenshot. This severely restricts the possibilities of using this feature to spy on what a user is doing. I just don't believe this is going to work. Screenshot applications I have seen are triggered by a key, yes, but all of them then show the initial screenshot to the user and then allow the user to change parameters and make a second screenshot. I suppose restricting the ui so that the user must hit the same key to trigger a second screenshot may work, but I am very worried about any scheme that forces ui decisions on clients. Yes, X11-style screenshot apps won't work but this is for a good reason, isn't it? And as far as I know, most users on Windows do not use any application for screenshots, they just press "print screen" and paste that in paint/whatever. With my proposed solution, the app would only be used to edit the screenshot (crop, resize). Different hot keys would be used depending on if you want to grab a window, a screen or all the screens. Is that that difficult onto users? Any other solution will result in lost confidentiality and, please, let wayland compositors be the only ones that cannot be spied on easily! Another concern is that a malware screenshooter could just fake it(maybe copying an old screenshot) and then delay until the critical time to take the screenshot. A timeout or cancel after too many other surfaces are created/destroyed may work but this is sounding like complexity to solve a pretty non-existent problem. Pressing another time would spawn another program, not increment a counter of "allowed screenshots". The video capture API concerns me more. But on Windows most fancy screenshooter applications do both. And users do not think of these as being different. Users do not think them as being different because that's what they learnt. Should we keep on doing the same mistakes and carry than legacy thinking? Should we loose confidentiality just for the fringe amount of users who want a common GUI for screenshooters across all wayland compositors? You know my answer... I think you just have to assume that the bound application is "good" and is doing what the user wants, even if it can take numerous screenshots or opens the video api. No constant access control == no security. Clients should never be trusted. I trust the server because it is the one implementing the service, but that's it. I'm not trying to be mean or anything, I'm just trying to map some expected requirements with what can be done. The only thing that concerns me is to find the solution that lowers the confidentiality risk while still being as usable as possible. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Screen shooting and recording protocols (Re: Authorized clients)
Le 09/01/2014 14:41, Pekka Paalanen a écrit : On Thu, 09 Jan 2014 13:05:28 +0100 Martin Peres wrote: There is a way to limit the memory consumption of apps that don't consume buffers. We could have a small ring buffer of wl_buffer or dma-buf (if we want 0 copy) on the compositor side. When the ring buffer is full, the compositor should not copy or store any new buffer. This way, it won't use up all the video memory. Yeah, that would be part of the failsafe, except the implementation details and protocol get complicated as you probably do not want the compositor to depend on the client in allocating the buffers the compositor is rendering into, which means you cannot use wl_drm. Or maybe you could... compositor has its own 2-3 private buffers it normally uses, and the recorder client could give it some "empty" buffers. The compositor renders into client's buffers one by one if they are suitable and not busy, *and* flips them on screen. As the fallback it can use its own buffers. That way the client is the one that gets "killed on OOM". Maybe that'd work. Oh, very interesting idea. I wouldn't have thought of that. Then, we need a way for the compositor to know when the user consumes a buffer. Having a simple "get_next_frame()" function returning the next wl_buffer or the next dma-buf fd would be enough. We could also tell that the semantics of the call means that the application should be done using a frame before requiring a new one. If we really want to be conservative, we could only use 2 entries in the ring buffer. This way, I don't think we would need any other form of synchronization, would we? Such a function would be higher level API than the protocol, since the wire protocol has no concept of a "return value". Yes, that should be all that's needed. "Here it is, just say when you're done." Oh, ok, so we would need two events then: - Compositor -> client: new image available in buffer index %i - Client -> compositor: buffer index %i has been processed and can be re-used That should be enough to map that to the PUT/GET pointers of a ring buffer. However, the ring buffer would need to be implemented on both side (compositor and client). In order to reduce the frame rate, another function in the protocol is needed to set the desired framerate otherwise a lot of copies will be made for no good reason, as Maarten rightly suggested! Not really. We want zero-copy, and then it's ok to push frames at the compositor's repaint rate (which is variable!). If the client doesn't need some of them, it just acks them without processing. I'm assuming a frame is sent only when the compositor repaints, i.e. something on screen changes. That's how the current recorder works, too. If we achieve 0-copy, then this is indeed what should be done. If we have to do copies, then it would be nice not to slow down memory by doing useless copies. It would thus need an indication of how many frames per second should be sent (or how many frames should be dropped). We do not want to cap the compositor's repaint rate with this in any case. Sure thing, yeah ;) Cheers, Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Screen shooting and recording protocols (Re: Authorized clients)
Le 09/01/2014 10:00, Pekka Paalanen a écrit : Hi, what I'm replying to has nothing to do with security anymore, so I changed the topic. The security issue is what and when can use a specific protocol interface, the below is about how to use the interfaces once you already have access This is indeed something that needs to be discussed independently of any security concern. On Wed, 8 Jan 2014 23:30:29 +0100 Maarten Baert wrote: On 08/01/14 13:52, Martin Peres wrote: I think the screenshot API and the video recording one should be separate. Ideally that's true, but it creates extra work for the compositor developers. And I don't see a huge benefit, actually. On X11 I can simply take 30 screenshots per second and this works great, the performance is about as good as it can get (2ms for a 1920x1080 frame, that's almost as fast as a simple copy) and the only issue is tearing (which is something that a good screenshot protocol should already solve, obviously we don't want tearing in screenshots either). So I would be perfectly happy with a screenshot interface that works just like X11 minus the tearing. Do we really need a separate API for that? There's another gray area here: what about timelapse videos? These are created by taking a screenshot every few seconds and then playing them back at much higher speed. Should such an application use the screenshot or the video API? There are differences in the implementation details of shooting (stills) vs. recording (videos). Weston supports (though disabled atm, AFAIK) hw overlays in addition to the GL renderer. To make a screenshot, the overlays are temporarily disabled, so that GL can composite the whole image which can then be sent to the shooting client. If you do repeated shooting, you probably end up doing a lot of useless back and forth work, enabling and disabling hw overlays. Also, shooting has one frame latency, because you have to wait for a repaint after you disabled the overlays. It will probably be quite hard to get a stable framerate. If the compositor knows we are doing recording instead of shooting, it can disable overlays for the whole duration. You only have the latency for the first frame, not all frames. There are probably other details that can be optimized, too. Shooting can easily be implemented like the current screenshooter protocol: a client creates a wl_buffer, and tells the compositor to fill it in. There is an inevitable copy, but since shooting is a rare action and usually triggered by the user directly, that cost is acceptable. The timing requirements are also very loose. That scheme might not work too well with recording, and achieving a zero-copy path to the video encoder will be hard. In that sense, the compositor autonomously pushing buffers to the client would be more performant, but then we have the problem of synchronizing buffer reads, writes, and re-uses. In the opposite direction, the synchronization was solved with the wl_surface.attach/commit and wl_buffer.release messages, but here an accidentally malfunctioning client has a greater risk to crash the compositor, if it does not return the buffers to the compositor in time, so the compositor needs a failsafe mechanism. Those are some reasons why screen recording (video) is easier to do as a compositor plugin, like it is currently in Weston. A separate client would need a non-trivial amount of new Wayland protocol to work well. There is a way to limit the memory consumption of apps that don't consume buffers. We could have a small ring buffer of wl_buffer or dma-buf (if we want 0 copy) on the compositor side. When the ring buffer is full, the compositor should not copy or store any new buffer. This way, it won't use up all the video memory. Then, we need a way for the compositor to know when the user consumes a buffer. Having a simple "get_next_frame()" function returning the next wl_buffer or the next dma-buf fd would be enough. We could also tell that the semantics of the call means that the application should be done using a frame before requiring a new one. If we really want to be conservative, we could only use 2 entries in the ring buffer. This way, I don't think we would need any other form of synchronization, would we? In order to reduce the frame rate, another function in the protocol is needed to set the desired framerate otherwise a lot of copies will be made for no good reason, as Maarten rightly suggested! If you need some information about the window the user picked, you need to embed that into the shooting and recording protocols. This is why I think we should have different hot keys so as the compositor can use the mouse cursor as an input of which window/screen should be grabbed, before even launching the recording app. Obviously, it will only work on devices with mice but I'm sure it could be translated to touch screens by remembering which application / screen recei
Re: Authorized clients
Le 08/01/2014 21:20, Sebastian Wick a écrit : Am 2014-01-08 19:53, schrieb Martin Peres: Le 08/01/2014 17:20, Sebastian Wick a écrit : Am 2014-01-07 15:07, schrieb Martin Peres: Those are extremely rare cases. Users wanting to do that should agree they give up confidentiality and should thus be administrators in order to tell the compositor that. Why should those people have worse security then others only because they want a feature you define as non-standard? That's not what I meant. I meant that if they want what you say you want to allow, they will de-facto loose some security (namely, confidentiality if the screenshot app is misbehaving). I don't understand you. You trust the compositor to do the right things, why shouldn't you trust a screenshot app to do the right things? I mean, if you make a screenshot via a key-binding you also trust weston-screenshooter to not screw up. You have to trust the application if you want to give it access to a privileged protocol. The compositor has to be trusted. It has access to all the application's output buffer. What we want is to avoid other apps from getting them unless that's what the user intended to. This intent can be known by the compositor through the input devices. We don't need to trust the client much if we limit the number of screenshots to 1. This way, the worse thing that could happen for your privacy would be if your cat sits on the keyboard and presses "print screen" all the time while you key in sensitive information (unlikely, right?), even if the app just When you trust an application to always do the right thing, it can abuse its power in the user's back and I don't like that. In this case, we can still restrict access to the interface to a handful of programs to lower the risks, but it will still be possible for these applications to spy on the user without him knowing and this is something that shouldn't be allowed by default. Like I said, we should be able to let polkit decide. You could even distribute a .rules file which white-lists an application if we pass the executable path. It is indeed something that is good, but insufficient because the trusted programs can do whatever they want and the compositor won't be able to tell if what they request really is what the user wants. Of course they can. Every client can do whatever they want. Even when taking a screenshot in weston via a key-binding you launch weston-screnshooter and it can do whatever it wants to do. The only way to be sure that it does exactly what you want it to do is by reading the source code. This is not true. The server can refuse to feed the application with more than one screenshot. This severely restricts the possibilities of using this feature to spy on what a user is doing. Simple example, you want a CLI application to be able to make screenshots and save them to a file. As an attacker, if I want a screenshot, I'll just run the program and get the screenshot. Is that something you think is OK, I definitely think this is not. It's not okay. You should not give the application permission to use the screenshoter protocol without further restrictions, then. If we would use polkit you could configure it so that the application gets access to the restricted protocol if it is started with root permission or after you entered your password. The only way I could possibly agree with you on this would be to have authentication on every call to the screenshot API with the following parameters: 1) full path of the app requesting that (if we can make sure of it when it has not been started by the compositor) 2) number of screenshots since the last time the "Print screen" event happened It seems 1) is doable ( http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket) and 2) should be doable. However, I don't like the idea of having to audit the policy on every wayland computer I will be on especially since I'm pretty sure some devs won't mind if their application is a privacy killer. Oh, and if you make a screenshot, no matter how, and save it to disk, it is readable by any other application you start. It's not our job to prevent that. I agree with that. Hence why we should limit the amount an app can make without user interaction. This is why I said the compositor shouldn't agree on a screenshot request if it can't tell if it was a user-made request or an app-made one. That's wrong. It should not matter who made the request. If you can use a program to exploit the security, the program is broken or has the wrong security settings. I want to make sure you understand the concept of indirect interactions. If program A cannot access the screenshot API but program B can and program B can be made to save the file automatically without the
Re: Authorized clients
Le 08/01/2014 20:20, Jasper St. Pierre a écrit : If the user installed an app that takes screenshots of the screen periodically and dumps them to a disk, I'd imagine that's functionality he wanted. Why would we prompt him? What if it is installed by default? And just because I sometimes want to do that, it doesn't mean I would like a malware to be able to call this program without me knowing. Seriously, we aren't here to make another security theater. Either we can make it secure or we don't. If it takes more than a second to think if it is safe or not, then it is too damn much complicated. What I propose is simple and very efficient. Sure it isn't as open as X11, but that's the point! Screenshots have a big security implication, whether you like it or not. Anyway, Daniel proposed something and I commented on it, you may actually think this is sufficient. Can you check please? I would really like if all of us could find a consensus :) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 08/01/2014 19:47, Jasper St. Pierre a écrit : Prompting the user "are you *sure* you really meant to take a screenshot? Yes/No" when he presses Print Screen is just a way to piss her off. Please don't mix everything and read carefully what I said. Pressing "Print screen" IS the event that proves the physical user of the computer wants it, not another app. No need for a popup. The pop up is only useful if no user intent is not known by the compositor. That is to say, when an app that didn't get run in response to a print-screen hot key tries to get a screenshot, it shouldn't be allowed without the user's consent. What Sebastian wants is simply to have a pool of trusted apps who can access restricted interfaces. I find this insufficient for the reasons I listed before (what happens if you install an app that allows taking screenshots and save them to a file automatically? without any input from the user? Well, you just lost the confidentiality of your display, too bad...). Cheers, Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 08/01/2014 17:20, Sebastian Wick a écrit : Am 2014-01-07 15:07, schrieb Martin Peres: Those are extremely rare cases. Users wanting to do that should agree they give up confidentiality and should thus be administrators in order to tell the compositor that. Why should those people have worse security then others only because they want a feature you define as non-standard? That's not what I meant. I meant that if they want what you say you want to allow, they will de-facto loose some security (namely, confidentiality if the screenshot app is misbehaving). In this case, we can still restrict access to the interface to a handful of programs to lower the risks, but it will still be possible for these applications to spy on the user without him knowing and this is something that shouldn't be allowed by default. Like I said, we should be able to let polkit decide. You could even distribute a .rules file which white-lists an application if we pass the executable path. It is indeed something that is good, but insufficient because the trusted programs can do whatever they want and the compositor won't be able to tell if what they request really is what the user wants. Simple example, you want a CLI application to be able to make screenshots and save them to a file. As an attacker, if I want a screenshot, I'll just run the program and get the screenshot. Is that something you think is OK, I definitely think this is not. This is why I said the compositor shouldn't agree on a screenshot request if it can't tell if it was a user-made request or an app-made one. The only solutions we found so far have been: - listen for hot keys from an input device (we have to trust the kernel for not allowing to forge events) - require a confirmation of some sort (popup / systray icon / whatever) The decision making is just what it is, a decision. This is an implementation detail. You propose to use polkit for the decision making, why not? But I think this is overkill since we only need a file in /etc/wayland/restricted_apps.d/ containing the full path of the authorized app and the interfaces that are allowed. You may be right. I meant for screen grabbing (images or videos), no idea what restricted interface could be useful for a wayland compositor. Any idea? The GNOME accessibility team need a few restricted protocols. Don't know about the details, though. I would be interesting in knowing what they have been thinking about! Would it be ok for you if the compositor asked the user to agree for the program to do the operation? If so, we can guarantee that this is really the user's intent and allow the application. We can also add a security warning with a "Do not ask again" checkbox. Would it be satisfactory to you? If an application has the permission to use an restricted protocol it already met all the requirements. You should talk to the polkit dev if you want such an feature, I guess. See, that's where we disagree. An app can get hijacked or used in conjunction with others apps to make it around the security policy you want to set. I used to work in a research security team and one of the project we used was PIGA which essentially is a language to define security properties and a compiler was then responsible for checking all the ways there was to violate the security property wanted (with the SELinux policy as an input of all the allowed operations). There were hundreds of thousands of ways to go around trivial security properties such as "do not allow a user-written file to be executable". Can you certify all the screenshot apps won't be able to be used in a malicious way, if not directly, indirectly? I can't and I think no-one can. I don't really like mandating compositors to implement that much code, but that's the only secure way I see to allow the uses cases you want to allow. And that's exactly why I don't want to implement the authorization checking in the compositor! We can safely let polkit decide in non-obvious cases. Less code in the compositor, less duplicated code and less security risks because polkit is designed to do that. Maybe. It doesn't solve the security issue though ;) By the way, I asked Peter about the security of input and that should be good. We then discussed about visual feedback as a mean to provide some mitigation and show some applications are grabbing the screen in the background. That may be something you would be interested in, in your case. What do you think? I'm personally not interested in it but I guess it's a nice feature for some people and I don't see why it should not work. I do see why it shouldn't work. It would not be standardized, users wouldn't understand, that would become annoying, users would deactivate it, unaware they are being spied on. __
Re: Authorized clients
Le 08/01/2014 15:04, Sebastian Wick a écrit : Am 2014-01-08 13:02, schrieb Martin Peres: On 07/01/2014 20:26, Jasper St. Pierre wrote: Would it be ok for you if the compositor asked the user to agree for the program to do the operation? If so, we can guarantee that this is really the user's intent and allow the application. We can also add a security warning with a "Do not ask again" checkbox. Would it be satisfactory to you? The user opened up a screen recording app. The user's intent is very much to record the screen. We don't need to ask the user again with a prompt. How do you make sure it WAS launched by the user and not run silently by one application? That's the whole problem. If the application starts recording the screen without user interaction I would consider it broken. Indeed, it would. Be security is never based on what an application SHOULD do, it is based on what it CAN do. So you want to trust every screenshot application? I don't think it is a good idea. It is a better one than trusting every app, but it still not is very efficient. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
On 07/01/2014 20:43, Pekka Paalanen wrote: On Tue, 7 Jan 2014 14:26:36 -0500 "Jasper St. Pierre" wrote: On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres wrote: Would it be ok for you if the compositor asked the user to agree for the program to do the operation? If so, we can guarantee that this is really the user's intent and allow the application. We can also add a security warning with a "Do not ask again" checkbox. Would it be satisfactory to you? The user opened up a screen recording app. The user's intent is very much to record the screen. We don't need to ask the user again with a prompt. For just screenshooting and recording, how about a simple setting "allow all programs capture the screen? yes/no" in the compositor's configuration dialog? Since it sounds like any automatic authentication/authorization scheme is going to hit cornercases. With that, write a screenshooting protocol interface, that is bindable for all clients, and informs the client whether capturing at will is allowed or not. When not, the client can show an informational message "Screen capturing is disabled in your compositor preferences." Make that support dynamic enable/disable and make access denied a non-fatal error. What I like about your dynamic enable/disable idea is that there is no storage of the settings that could be abused by other apps (since they are usually run with the same user as the compositor). If we want to make the setting permanent (for whatever stupid reason one may have), it should require root access to store this setting. I think making sure the user really is the one who launched the app (by letting the compositor launch it for us) is really a lesser evil and should cover all the cases. No need to add complexity by creating new protocols to require privileges (I already implemented one and it is hard to make it right, and I'm not even talking about the fact it requiring a policy!). I think the screenshot API and the video recording one should be separate. For the configuration of the screenshot, I see two cases. Either we just want the compositor to grab the image and pass it to an application [1] or we want the screenshotting app to be able to be able to query the number of screens and windows and their positions. The first doesn't require a Wayland protocol, the second does however require a privileged protocol. If we go for the second solution (which could make sense for other use cases), we should limit the number of screenshots the app can make, otherwise we cannot make sure the app really exited and is not grabbing the screen all the time. I am however willing to live with that if the default-screenshot app can only be changed as root or as a run-time change. Another possibility would be to advise to use [1] by default and the second solution would be the less-secure fallback that doesn't restrict the user much. Any thoughts? As for the video grabbing API, I see the same solutions. Different hotkeys could automatically grab the screen content (either by window or screen) or it could be queried using the screen/window layout query protocol. Once the screen capture has been set up, a stream of DMA-buf (or shm) should be sent to different program that would record the output to whatever format one wants (stream of png or video) using either sw or hw encoders. Both the first and second case would use an external program to select the output format and encoding method. The good thing is that this encoding program would be compositor-independent and could be shared by all of them. Weston could then get rid of his VA-encoder and just use this new protocol. The good thing about sending a stream of images is that we get explicit synchronization between the compositor and the screen grabbing app which means it can miss no frames nor sample the same one twice (unless that's what the app wants). Again, any thoughts on this? Cheers, Martin [1]: The screenshot "API" could just grab an image based on what hotkey is used: - window under the cursor - current screen (where the cursor is) - all the screens I'm not sure how to do that on touch devices, but this is a compositor implementation detail. Once the image is grabbed, the compositor should either save the file somewhere or pass it to an application. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
On 07/01/2014 20:26, Jasper St. Pierre wrote: Would it be ok for you if the compositor asked the user to agree for the program to do the operation? If so, we can guarantee that this is really the user's intent and allow the application. We can also add a security warning with a "Do not ask again" checkbox. Would it be satisfactory to you? The user opened up a screen recording app. The user's intent is very much to record the screen. We don't need to ask the user again with a prompt. How do you make sure it WAS launched by the user and not run silently by one application? That's the whole problem. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
On 07/01/2014 20:53, Daniel Stone wrote: Hi, On 7 January 2014 19:22, Maarten Baert wrote: @Martin Peres: Your ideas are nice in theory, but as Sebastian Wick already said, it is just not practical. If you want a specific example, I have one: https://github.com/MaartenBaert/ssr The sole purpose of this application is to record the screen (i.e. take 30 screenshots per second). People are using this - the latest version has been installed about 13.000 times on Ubuntu alone (and that number is still growing). I know that's not a lot in the big picture, but clearly it is not an 'extremely rare case'. I really want to add Wayland support to this application. In fact that's why I'm here, discussing an API to authenticate my program so I can actually start to think about adding Wayland support. Your answer seems to be that the user should continuously hold down a button on their keyboard in order to record their screen. That's just not acceptable. I will simply have to tell users to disable the security features in Weston completely so they can use my application - and most of them will probably have no problem with that, because the average user doesn't care about security, especially when it is something trivial like the ability to take screenshots. Seriously - a rogue application can install a keylogger, steal my saved passwords and browser cookies, ssh and pgp keys, delete all my files and even my backups, but luckily it can't take screenshots! I do not want to tell users to disable security features, but if these features make it completely impossible for an application to function, then I have no choice. Alternately, you can just have a hotkey which triggers video recording, or since your compositor's likely to be the one launching your screen recorder, it already knows that the client is trusted to, well, record the screen. Right, an application that wants to capture the screen continuously is a video recording app and should be treated as such by the compositor. It is OK if a screenshot application forces a copy of the framebuffer but do we really want video recording to trigger 30 copies of the framebuffer per second or do we want to use DMA-buf to the video-recording tool so as it can use sw or hw compression techniques? This isn't a security question, this is just getting rid of this X11 idea that video grabbing means taking snapshots several times per second without synchronization. My point is that the screenshot interface shouldn't be used for video recording. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
Le 07/01/2014 01:45, Sebastian Wick a écrit : Am 2014-01-06 19:33, schrieb Martin Peres: Le 06/01/2014 19:10, Sebastian Wick a écrit : Am 2014-01-06 16:05, schrieb Martin Peres: As I said before, I think trusting applications is taking the problem the wrong way. What we want is that a screenshot can only happen when the *user* wants it. This is why I think it is the desktop shell's job to launch the screenshot app when required by the user. In this case, even if the user can select the application that can perform a screen shot and even if a malicious application changes the default setting, it won't be able to perform screenshots silently. This is what we want. It's just not flexible enough. What if you want to autostart a screen-reader? Please provide a better example, this one doesn't make sense. Who would want that? And if they do want that, they should press a button on their keyboard to do just that. Taking a screenshot from the command line with delay, recording the desktop as soon as a program starts. Making screenshots at a specific times. There are some valid cases you can't even think of until someone wants it. Those are extremely rare cases. Users wanting to do that should agree they give up confidentiality and should thus be administrators in order to tell the compositor that. In this case, we can still restrict access to the interface to a handful of programs to lower the risks, but it will still be possible for these applications to spy on the user without him knowing and this is something that shouldn't be allowed by default. Is it something that would be satisfactory to you? My proposal is that it should require a physical key pressing to be able to get ONE screenshot means we also require a secure input method and can attest the origin of the key stroke but what else can be do? Of course, you should also allow key strokes from the on-screen keyboard, but this application should be launched by the compositor and should be trusted anyway. I should talk to Peter Hutterer about input security/origin. Like I said, I think it's too inflexible. Please, share a list of valid use cases :) I already gave reasons why I think not doing what I proposed almost means no confidentiality on the application's buffers. Of course, it could be mitigated by making the screen flash or something when a screenshot is taken but people just hate that and some would even fail to notice it. What you want is allowing apps to grab the screen whenever you want. Allowing that should mean you have root/admin access. A global configuration file could disable the screenshooting security, but that should be a conscious choice of the administrator (for whatever weird reason they want to be able to grab the screen). However, I re-iterate, this is something stupid security-wise for very little benefit. Why don't you want to associate a physical event to start the recording process? I just don't agree that a restricted protocol is only useful if the user interacts with it. You may be right. I meant for screen grabbing (images or videos), no idea what restricted interface could be useful for a wayland compositor. Any idea? That also means that we need a protocol to tell the compositor to start a program with a new socket and a protocol to ask the compositor for permission. Why do you want to create so many protocols? The compositor simply has to create a new connection to itself, mark this connection as being allowed to do one screenshot, then fork. The child should then exec the wanted process. The new process will simply access the already-opened fd and communicate with the server with it (yes, some FDs from the parent can still exist in the child process, after the exec). That should be the way for privileged application to communicate with the compositor. No authentication protocol needed, the compositor is responsible for doing the authentication the way it pleases him. You're right about the authentication protocol but there must be a way to tell the compositor to start an application without having a key-binding or such a thing. When a client uses the protocol, the compositor would then do what you described. Would it be ok for you if the compositor asked the user to agree for the program to do the operation? If so, we can guarantee that this is really the user's intent and allow the application. We can also add a security warning with a "Do not ask again" checkbox. Would it be satisfactory to you? I don't really like mandating compositors to implement that much code, but that's the only secure way I see to allow the uses cases you want to allow. By the way, I asked Peter about the security of input and that should be good. We then discussed about visual feedback as a mean to provide some mitigation and show some applications are grabbing the screen in
Re: Authorized clients
Le 06/01/2014 19:10, Sebastian Wick a écrit : Am 2014-01-06 16:05, schrieb Martin Peres: As I said before, I think trusting applications is taking the problem the wrong way. What we want is that a screenshot can only happen when the *user* wants it. This is why I think it is the desktop shell's job to launch the screenshot app when required by the user. In this case, even if the user can select the application that can perform a screen shot and even if a malicious application changes the default setting, it won't be able to perform screenshots silently. This is what we want. It's just not flexible enough. What if you want to autostart a screen-reader? Please provide a better example, this one doesn't make sense. Who would want that? And if they do want that, they should press a button on their keyboard to do just that. Let's not repeat X11's mistakes. Being too lax on security isn't good for anyone. By allowing some programs (and not the action), you expose yourself to letting the application record the screen without the user knowing and this is not acceptable. You would only allow certain functionality to trusted programs. If the program does something unexpected or malicious you should not trust the program. You would also know which program uses which functionality so you could inform the user about it. See, I hate the term "trusted". Just because a program is trusted doesn't mean it is cannot do anything malicious at some point. Even malicious doesn't mean much since, to me, malicious means doing something without the user expecting it. My proposal is that it should require a physical key pressing to be able to get ONE screenshot means we also require a secure input method and can attest the origin of the key stroke but what else can be do? Of course, you should also allow key strokes from the on-screen keyboard, but this application should be launched by the compositor and should be trusted anyway. I should talk to Peter Hutterer about input security/origin. Like I said, I think it's too inflexible. Please, share a list of valid use cases :) I already gave reasons why I think not doing what I proposed almost means no confidentiality on the application's buffers. Of course, it could be mitigated by making the screen flash or something when a screenshot is taken but people just hate that and some would even fail to notice it. What you want is allowing apps to grab the screen whenever you want. Allowing that should mean you have root/admin access. A global configuration file could disable the screenshooting security, but that should be a conscious choice of the administrator (for whatever weird reason they want to be able to grab the screen). However, I re-iterate, this is something stupid security-wise for very little benefit. Why don't you want to associate a physical event to start the recording process? Martin, I would rather not use cgroups for that because it isn't stable yet and I'm sure we can find a solution that doesn't depend on it. I do agree on this one but I'm not even sure how cgroups would be useful. The problem we have is relatively simple. We want a protocol to be restricted to certain clients. Which means: 1. The program of the client must not be manipulated by ptrace, LD_PRELOAD etc. 2. The communication must be separate from other clients to prevent snooping 3. The compositor must decide if a client may use the protocol or not The only way I know to achieve 1. is by starting the program by another trusted application. The compositor is one of them. Making the communication separate works by passing a new socket to the program and the only way I know of is by passing it to the program when starting it. To decide if a client may use a protocol we could outsource the whole decision to polkit and just pass enough information so it can make a good decision. All in all I think the best and most simple way to do it is by starting the program by the compositor, passing a new socket, then let the client ask for permission to use a protocol and pass the request to polkit. The permission would be per-connection so if a program started by the compositor starts another program with a client it would have the same permission as the parent. Fully agree on this. That also means that we need a protocol to tell the compositor to start a program with a new socket and a protocol to ask the compositor for permission. Why do you want to create so many protocols? The compositor simply has to create a new connection to itself, mark this connection as being allowed to do one screenshot, then fork. The child should then exec the wanted process. The new process will simply access the already-opened fd and communicate with the server with it (yes, some FDs from the parent can still exist in the child process, after the exe
Re: Authorized clients
Le 04/01/2014 11:01, Martin Graesslin a écrit : On Tuesday 31 December 2013 05:02:30 Sebastian Wick wrote: I'm currently working on a system which allows specific clients to use restricted interfaces [1]. This is needed for applications like screenhooters, desktop recorders outside of the compositor, accessibility tools and others. Thanks for looking into this interesting topic. It's an important use case for us in the KDE world as compositor and desktop shell are in different processes. I will try to share my thoughts so far and I must say that I don't know whether that's implementable at all. Of course we also thought about working with full paths, but I don't think that's a good solution for a flexible desktop environment such as Plasma. Also it creates a terrible linear chain in the startup - we want to move to a more flexible framework and don't turn KWin into another system startup process. It might be a solution for things like KSnapshot but certainly not to bring up the desktop shell. The idea I have so far is to depend on cgroups and namespaces. Thus everything which needs the more privileged interfaces needs to be in the "desktop shell" cgroup. I hope that we can make use of systemd to provide us such features. Clients which are not in the trusted group will not get the more exposed interfaces. This could also work for things like screenshooters, but here we start to enter trust issues again. We certainly would trust a KDE application, but that's already quite borderline. For such cases so far I only have the idea of nag screens like UAC. I hate that and absolutely don't want to implement it. So I'm looking forward for good solutions. Polkit could be a nice solution to that. I'm not so sure about configuration files as I don't believe in whitelists in general :-) Obviously it allows the distribution to properly setup the system but there might be better solutions to that. My suggestion here is to specify the interfaces in the desktop file. Cheers Martin As I said before, I think trusting applications is taking the problem the wrong way. What we want is that a screenshot can only happen when the *user* wants it. This is why I think it is the desktop shell's job to launch the screenshot app when required by the user. In this case, even if the user can select the application that can perform a screen shot and even if a malicious application changes the default setting, it won't be able to perform screenshots silently. This is what we want. By allowing some programs (and not the action), you expose yourself to letting the application record the screen without the user knowing and this is not acceptable. My proposal is that it should require a physical key pressing to be able to get ONE screenshot means we also require a secure input method and can attest the origin of the key stroke but what else can be do? Of course, you should also allow key strokes from the on-screen keyboard, but this application should be launched by the compositor and should be trusted anyway. I should talk to Peter Hutterer about input security/origin. The proposed authentication scheme you are trying to propose can however act as a second level of security so as only trusted (by the distro) apps would be able to be grab the screen. Martin, I would rather not use cgroups for that because it isn't stable yet and I'm sure we can find a solution that doesn't depend on it. Cheers, (The other) Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] introduces a setting to give permission to any client to do screenshots
On 15/12/2013 01:09, Sebastian Wick wrote: Am 2013-12-13 16:12, schrieb Martin Peres: What prevents other applications from modifying this setting to true if they want to spy on applications? Nothing. But then again if you can write to the ini file you can make the compositor load any code with the shell setting. Not if the compositor was loaded by the init system. I don't even think my patch is the right way to handle it anymore. There must be a way to trust a client even when it's not started by the compositor. I think there is one, but it is not super pretty: Write the list of acceptable screenshot clients in an administrator-owned file. The file could either be global (in /etc/) or local (in ~/.wayland/). To be found acceptable by weston, it would have to be owned by root and in 644. In order to be considered "secure", the screenshot app shouldn't be able to take snapshot without the user's consent or, at least, the user should notice about it. That means no CLI-only interface without, at least, some sort of graphic notification. Of course, we shouldn't deny the user from using unsecure screenshot apps, but let's not make that possible for a program run by the user to change the setting for him, this is why we need the administrator for that (or at least a confirmation of the user's password, like sudo). What do you think? Cheers, Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Limitations of Weston's screenshooter / Are there any plans to create an official screenshot protocol?
Le 13/12/2013 18:57, Maarten Baert a écrit : On 13/12/13 16:01, Martin Peres wrote: I may be wrong, but other unix users shouldn't be able to communicate with another user's compositor unless this user specifically allowed that by adding him to his/her group. Okay, then that's not an issue. Screenshot/screencapture applications are a confidentiality hazard. We don't want any application run by the user to be able to read the credit card number you are writing in firefox, right? True, but sadly there are many other ways for applications to steal data from other programs, if both applications are running as the same user. Right, but that's no excuse for making it harder for people who want to control the security of their system. In view of the current events, we should really propose something that is as secure as possible *by default* and make it as easy as possible to improve with simple MAC rules (path- or label-based) for distros who want to focus on security. A rogue application could simply read the firefox profile and steal cookies and passwords. Right, but we are talking about input here. Users never store their credit card numbers on the computer since they always carry them. Users do not understand other applications can snoop on input or output and it freaks them out when they are told. In fact, it could install a fake firefox (or replace 'sudo', or even the wayland server) simply by changing PATH in ~/.profile. If attackers become root, then all hell breaks loose. Let's not talk about this, it has nothing to do with Wayland. Or it could use LD_PRELOAD to inject a library and override any system or library function it wants (e.g. wl_keyboard_add_listener). I can write a proof-of-concept 'Wayland keylogger' to demonstrate it, if you want. This is indeed the only issue in input/output security I want to have in the final system. This problem can be solved by using a different linker or using SELinux (AT_SECURE or simply not allowing applications to read shared library outside of the trusted /usr. In any way, this is a very valid concern, but it is a mistake of the application/packager if it allows loading arbitrary code at run time. A simple restriction in Weston is not enough to stop this. Only a system like SELinux can fix this. With this in mind, I think the ideal authentication system would be one that integrates well with existing security/sandboxing mechanisms so that it can be enabled with minimal hassle in places where it's important, while accepting that local applications running outside the sandbox simply can't be stopped from doing bad things. The current solution just gives a false sense of security IMHO. People are usually aware of the problems you talked about. The PATH issue can be mitigated by having user-writable folders in different partitions and using the mount option noexec to avoid being able to run binaries outside of /usr. The graphics stack is very obscure to almost everyone and I don't want to ask our users to learn how to defend themselves in new ways! What I think is important here, is that no application can perform a snapshot without the user being aware of it. I wonder what compositor-provided visual cue could be a good idea to signal a snapshot has been taken. I have no experience with SELinux so I'm not sure how such a mechanism should work. But it seems that both X11 and PulseAudio use a cookie mechanism, where they put a random string (e.g. from /dev/urandom) in a file in the home directory of the user. The file mode is 600 so only the owner can read it. Wayland could use a similar mechanism, except that the cookie would only be needed for unsafe actions like taking screenshots or listening to global hotkeys. SELinux can then block applications that want to open that file. Since the cookie is simply a random string, it can be easily transferred to an application that would otherwise not be allowed to read it. For example, an untrusted application that isn't allowed to read the cookie directly could run a trusted application which would show a popup asking the user whether the untrusted application should be allowed to capture the screen. If the user accepts, the trusted application will read the cookie and give the result to the untrusted application. This is only an example of course, but it shows one big advantage of this approach; it separates the security/sandboxing mechanism from the compositor, and the only thing the compositor has to do is write a random string to a file at startup. The same security/sandboxing mechanism would be compatible with any wayland compositor that follows this simple protocol. Every MAC implementation should be able to work with your proposed solution and it doesn't sound ridiculous to require screenshot applications to have policy written for them. However, we would be leaving the DAC-only users (the VAST majority
Re: [PATCH weston] introduces a setting to give permission to any client to do screenshots
Le 04/12/2013 17:38, Sebastian Wick a écrit : diff --git a/weston.ini.in b/weston.ini.in index 5181a9e..bc32567 100644 --- a/weston.ini.in +++ b/weston.ini.in @@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard #constant_accel_factor = 50 #min_accel_factor = 0.16 #max_accel_factor = 1.0 + +#[screenshooter] +#restrict-access=false What prevents other applications from modifying this setting to true if they want to spy on applications? This parameter (or any security-related one) should require root-access to be changed. A solution could be to put security parameters in a separate configuration file that should be owned by root with access rights set to 644 in order to be used by weston. If you have other ways to avoid this problem that do not require mandatory access control, I'm interested in hearing them! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Limitations of Weston's screenshooter / Are there any plans to create an official screenshot protocol?
Le 13/12/2013 15:26, Maarten Baert a écrit : I'm trying to add Wayland support to a screen recording application, but I'm running into a few issues: - There is no official protocol. I'm using the weston-specific 'screenshooter' interface now, but I don't want to use a different interface for every possible Wayland compositor in the future. Are there any plans to create an official screenshot protocol? - Permissions were an issue, but I hear this is being taken care of. The current solution is to drop the restriction completely for all clients - wouldn't it be safer to add a third mode where only local clients running as the same user are allowed to capture the screen? I may be wrong, but other unix users shouldn't be able to communicate with another user's compositor unless this user specifically allowed that by adding him to his/her group. I think this mode would be more suitable for a typical Linux desktop (local applications can already do far more damage in other ways). Screenshot/screencapture applications are a confidentiality hazard. We don't want any application run by the user to be able to read the credit card number you are writing in firefox, right? More exactly, we don't want non-user-triggered application to be able to grab the screen. This is why I advocated for the screenshot application to be managed by the compositor because we already have to trust it and because it has access to the input from evdev and can control global shortcuts. I am not entirely satisfied by the idea that it is possible to disable any access control by a configuration file because any application could modify the setting and, at the next reboot, your system would become vulnerable. Of course it is possible to use SELinux to restrict access to this file (or make it root-owned and read-only access to the user) but I see valid use cases where someone would genuinely want a behaviour like that. Anyway, the bottom line is that I strongly think only the compositor should be able to run screenshot applications and those (or the compositor) should at least make it obvious to the user that screenshots are being taken. It doesn't mean that I disagree that there should be a good screenshot interface for compositors, I actually think you are fully right on this! Martin Peres ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] X/Graphics DevRoom at FOSDEM 2012? (4-5 February)
Le 20/09/2011 12:32, Luc Verhaegen a écrit : So far, only Martin Peres has stepped up and stated "yes! I will be there!", and he will be happy to give FOSDEM visitors a talk about Nouveau. Yep, count me in. I'm really looking forward to it! Living in France and never attending FOSDEM is a shame! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
