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-trivia

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Fri, 10 Jan 2014 20:38:46 +0100 Maarten Baert wrote: > Is this multi-view functionality inherent to the way Wayland > works, or is it Weston-specific? Will other compositors easily be > able to implement this in the same way? Multi-view is a Weston feature AFAIK, but it does not depend on any

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 19:47, Bill Spitzak wrote: > I think "recording a window" sounds a lot like another output (as in a > montior). Then all the existing multi-view stuff can be reused to > duplicate the window into this output, including controlling whether > child surfaces are shown. Is this multi-view f

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 > 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 a

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

Re: Screen shooting and recording protocols (Re: Authorized clients)

I'm pretty certain what is being requested is a rectangle of some output. The video recorder will record whatever pixels are inside that rectangle, even if the surface used to choose it is moved away from it or if other surfaces enter it. The compositor must be able to set a stride value on th

Re: Authorized clients

On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres 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 ker

Re: Authorized clients

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 man

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 17:10, Pekka Paalanen wrote: > What you call capturing a window, is just capturing a sub-rect of the > screen for me. For me, capturing a window is a different thing, it > gets the original window contents. Okay, window capturing is probably not the right word to describe it. It's ess

Re: Screen shooting and recording protocols (Re: Authorized clients)

Am 2014-01-10 17:10, schrieb Pekka Paalanen: Well, if the user wants to capture it like that, maybe she rather takes a shot of the whole desktop? Maybe I'm just weird, but when I think about capturing a single window, I really think about the window contents, not how it is presented on screen. I

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 direct

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Fri, 10 Jan 2014 15:26:19 +0100 Maarten Baert wrote: > On 10/01/14 09:54, Pekka Paalanen wrote: > > I think it is realistic on good platforms, and also essential for > > performance. Needs to be tried out, of course. > X11 does capturing by simply copying the buffer to a SHM image. This > take

Re: Authorized clients

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, u

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 09:54, Pekka Paalanen wrote: > I think it is realistic on good platforms, and also essential for > performance. Needs to be tried out, of course. X11 does capturing by simply copying the buffer to a SHM image. This takes about 2ms for a 1920x1080 frame. That's perfectly usable, consider

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 > 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 runnin

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

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 (screensho

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Thu, 9 Jan 2014 22:38:47 +0100 Maarten Baert wrote: > But I agree that if the compositor is able to capture frames with zero > overhead, then the compositor should just capture every frame and let > the application decide. Is this realistic? I think it is realistic on good platforms, and also

Re: Authorized clients

On 10/01/14 04:32, Jasper St. Pierre wrote: > 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

Re: Authorized clients

On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres 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 >

Re: Authorized clients

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 >

Re: Authorized clients

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 diff

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 re

Re: Authorized clients

On 09/01/2014 22:16, Jasper St. Pierre wrote: On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres > 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 ca

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.c

Re: Authorized clients

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 ins

Re: Authorized clients

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

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 09/01/14 20:14, Bill Spitzak wrote: > My quick impression is that a framerate hint is not needed. Instead > they are throttled by the client not releasing the buffers. I tried that the first time I implemented OpenGL recording (using a 5-frame ring buffer). It worked, kind of, but the frame rate

Re: Authorized clients

On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres 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

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

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 a

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 09/01/14 10:00, Pekka Paalanen wrote: > 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

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

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 whi

Re: Authorized clients

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. 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?

Re: Authorized clients

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

Re: Screen shooting and recording protocols (Re: Authorized clients)

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.

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Thu, 09 Jan 2014 15:15:48 +0100 Martin Peres wrote: > 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

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

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Thu, 09 Jan 2014 13:05:28 +0100 Martin Peres wrote: > 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, t

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 i

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 b

Screen shooting and recording protocols (Re: Authorized clients)

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. On Wed, 8 Jan 2014 23:30:29 +0100 Maarten Baert wrote:

Re: Authorized clients

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

Re: Authorized clients

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 composi

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 t

Re: Authorized clients

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? On Wed, Jan 8, 2014 at 2:17 PM, Martin Peres wrote: > Le 08/01/2014 19:47, Jasper St. Pierre a écrit : > > Prompting the

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 p

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

Re: Authorized clients

Yes, the user has to trust that a screenshot app won't start uploading his porn to the web, just like she also has to trust that it won't give him a virus. The new sandboxing technology is a way of making sure the user knows what the app has access to, and to prevent access to things the user didn

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 t

Re: Authorized clients

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

Re: Authorized clients

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 applicat

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

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

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 purpo

Re: Authorized clients

As Stef Walters explains in his excellent GUADEC talk from last year, never prompt the user to make a security decision while they're trying to do something. You will get worse results than random chance. [0] UAC is fairly unpopular with people. If I'm launching something like SSR or OBS to stream

Re: Authorized clients

On Tue, 7 Jan 2014 15:00:31 -0500 "Jasper St. Pierre" wrote: > On Tue, Jan 7, 2014 at 2:43 PM, 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 yo

Re: Authorized clients

On Tue, Jan 7, 2014 at 2:43 PM, 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 o

Re: Authorized clients

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 reco

Re: Authorized clients

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 int

Re: Authorized clients

On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres wrote: > 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 trustin

Re: Authorized clients

@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

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 screens

Re: Authorized clients

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.

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

Re: Authorized clients

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 requir

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 compos

Re: Authorized clients

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/14 11:01, Martin Graesslin wrote: > 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 solu

Re: Authorized clients

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. Tha

Re: Authorized clients

On 03/01/14 03:27, Sebastian Wick wrote: > Am 2014-01-03 02:19, schrieb Maarten Baert: >> Okay, so the path in the config file is indeed the path to the >> executable that will be launched by the Wayland compositor, and not >> the path of the executable that _sends the request_ to launch a >> (di

Re: Authorized clients

2014/1/3 Maarten Baert : > > So far your protocol sounded secure, but I think this is where it breaks > down. You're leaving the Wayland server open to a confused deputy attack, > and also a social engineering attack. And also please consider the following "hammer-based" attack. A piece of malware

Re: Authorized clients

Am 2014-01-03 02:19, schrieb Maarten Baert: Okay, so the path in the config file is indeed the path to the executable that will be launched by the Wayland compositor, and not the path of the executable that _sends the request_ to launch a (different) privileged executable, right? Just checking :

Re: Authorized clients

On 03/01/14 00:12, Sebastian Wick wrote: > Maybe I should have made it more clear. The client must be started by > the compositor and it needs permission from either a config file or > polkit. The patches introduce a new protocol which lets a client tell > the compositor to start a new program/cli

Re: Authorized clients

Am 2014-01-02 23:01, schrieb Maarten Baert: On 31/12/13 05:02, Sebastian Wick wrote: I haven't looked at your code yet, but I suspect this detection mechanism would be seriously flawed, because it doesn't consider the environment of the application (chroot, LD_PRELOAD, LD_LIBRARY_PATH, the Qt an

Re: Authorized clients

On 31/12/13 05:02, Sebastian Wick wrote: > A client is authorized for a protocol if... > a) the client's executable path is found in a config file in the > directory > /etc/xdg/wayland/auth.d and if the config allows access on the protocol I haven't looked at your code yet, but I suspect this detec

Authorized clients

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. The current implementation consists of a protocol which can be used