On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres <martin.pe...@free.fr> 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 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? > 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. > 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 the background. That may be > something you > would be interested in, in your case. What do you think? > > > >> Polkit should be flexible enough to allow a protocol based on how a >>>> program >>>> was started. You could configure polkit that if the compositor started >>>> a program >>>> because of a key-binding it has permission to use a protocol and stuff >>>> like that. >>>> >>> >>> I haven't studied polkit, I don't know. >>> >> >> I'm going to ask someone who knows more about polkit but from what I >> understand we >> can pass arguments to polkit rules. >> We don't even have to argue about if only clients started by a user >> action get >> permission because we can simply pass to polkit if the client was started >> by a user >> action and let polkit decide. >> > > Great, please report back! > > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
