<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 08/01/2014 21:20, Sebastian Wick a
      écrit :<br>
    </div>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">Am 2014-01-08 19:53, schrieb Martin Peres:
      <br>
      <blockquote type="cite">Le 08/01/2014 17:20, Sebastian Wick a
        écrit :
        <br>
        <blockquote type="cite">Am 2014-01-07 15:07, schrieb Martin
          Peres:
          <br>
          <blockquote type="cite">Those are extremely rare cases. Users
            wanting to do that should agree
            <br>
            they give up
            <br>
            confidentiality and should thus be administrators in order
            to tell the
            <br>
            compositor that.
            <br>
          </blockquote>
          <br>
          Why should those people have worse security then others only
          because
          <br>
          they want a feature you define as non-standard?
          <br>
        </blockquote>
        <br>
        That's not what I meant. I meant that if they want what you say
        you
        <br>
        want to allow,
        <br>
        they will de-facto loose some security (namely, confidentiality
        if the
        <br>
        screenshot
        <br>
        app is misbehaving).
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <br>
    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 <br>
    <br>
    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.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">In this case, we can still restrict
            access to the interface to a
            <br>
            handful of programs
            <br>
            to lower the risks, but it will still be possible for these
            <br>
            applications to spy on the user
            <br>
            without him knowing and this is something that shouldn't be
            allowed by default.
            <br>
          </blockquote>
          <br>
          Like I said, we should be able to let polkit decide. You could
          even distribute
          <br>
          a .rules file which white-lists an application if we pass the
          executable path.
          <br>
        </blockquote>
        <br>
        It is indeed something that is good, but insufficient because
        the
        <br>
        trusted programs
        <br>
        can do whatever they want and the compositor won't be able to
        tell if what they
        <br>
        request really is what the user wants.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      <blockquote type="cite">Simple example, you want a CLI application
        <br>
        to be able to make screenshots and save them to a file.
        <br>
        <br>
        As an attacker, if I want a screenshot, I'll just run the
        program and
        <br>
        get the screenshot.
        <br>
        Is that something you think is OK, I definitely think this is
        not.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    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:<br>
    1) full path of the app requesting that (if we can make sure of it
    when it has not been started by the compositor)<br>
    2) number of screenshots since the last time the "Print screen"
    event happened<br>
    <br>
    It seems 1) is doable (
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <a
href="http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket">http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket</a>)
    and 2) should be doable.<br>
    <br>
    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.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      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.
      <br>
    </blockquote>
    <br>
    I agree with that. Hence why we should limit the amount an app can
    make without user interaction.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      <blockquote type="cite">This is why I said the compositor
        shouldn't agree on a screenshot
        <br>
        request if it can't
        <br>
        tell if it was a user-made request or an app-made one.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    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 user knowing, then program A can call
    program B and get whatever he wanted (I never trust a screenshot app
    to do the right thing).<br>
    <br>
    Is program B buggy or illegitimate? No, it does exactly what the
    user wants and is fine on its own.<br>
    Does it trash the graphics output confidentiality of the whole
    computer? Yes!<br>
    <br>
    What if I use a computer and someone installed such an app (shared
    computer, for instance)? Well, I won't know I lost the
    confidentiality. Too bad....<br>
    <br>
    This is why we need the user's input, either a run-time enable as
    Pekka suggested or a hot key one as I suggest. Both can be
    implemented if needed, they cover different use cases.<br>
    <br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      If you have a screenshot UI and it gets started (by whoever) the
      user must do something for the application to actually take the
      screenshot, otherwise it's broken.
      <br>
      <br>
      If you have a command line app to make screenshots and someone or
      something wants to start it there must be some kind of user
      interaction to confirm it.
      <br>
    </blockquote>
    <br>
    I fully agree here but contrarily to you, I don't want to trust the
    application. Anyway, glad to see we are on almost the same page ;)<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      If you press a key-biding and the compositor starts an application
      to make a screenshot there doesn't need to be a confirmation. We
      simply start the app and be done with it.
      <br>
    </blockquote>
    <br>
    Yes, but only a physical user can press this key. This is like
    pressing a button on the screen with a mouse.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      So we can have a configuration which only allows access to
      restricted protocols if the user agrees to it (or something else,
      this is really up to the one who configures the system). If the
      request to start the application comes from the compositor itself
      we can safely assume that everything is fine and start to app. If
      the request to start the application comes from another client, we
      check the configuration. If the configuration says it's fine to
      start the app, we do so (however it will determine if it's okay or
      not; maybe the app is configured to just start, maybe the app is
      configured to require the user to press on a "yes" button, maybe
      the app is configured to require the user to enter his password or
      maybe it is simply configured to deny the request).
      <br>
    </blockquote>
    <br>
    Yep, that would be a good fallback but as I said before, if someone
    installs such an app on my computer and it can do screen captures
    without my interaction, then I just lost the confidentiality of my
    desktop. I just don't like the concept of not further checking how
    the app is using the interface.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      <blockquote type="cite">The only solutions we found so far have
        been:
        <br>
        - listen for hot keys from an input device (we have to trust the
        <br>
        kernel for not allowing to forge events)
        <br>
        - require a confirmation of some sort (popup / systray icon /
        whatever)
        <br>
      </blockquote>
      <br>
      Like I said, we can configure certain application to not require a
      confirmation dialog.
      <br>
      <br>
      <blockquote type="cite">The decision making is just what it is, a
        decision. This is an
        <br>
        implementation detail.
        <br>
        You propose to use polkit for the decision making, why not? But
        I
        <br>
        think this is overkill since
        <br>
        we only need a file in /etc/wayland/restricted_apps.d/
        containing the
        <br>
        full path of the authorized
        <br>
        app and the interfaces that are allowed.
        <br>
      </blockquote>
      <br>
      Some apps might need some confirmation (however it will look) like
      command line screenshooters or applications which are not
      installed and thus have no configuration file in
      /etc/wayland/restricted_apps.d/ which would allow them to use a
      restricted protocol. I guess there are even more cases.
      <br>
      <br>
      Essentially we need 3 parameters: the full path of the app,
      allowed interfaces and if the app requires user input. If the
      doesn't require input or has no configuration, we must present the
      user a confirmation dialog.
      <br>
    </blockquote>
    <br>
    It would work if you trust the screenshot application.<br>
    <blockquote
      cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net"
      type="cite">
      <br>
      I would be okay with that but I think an external program would be
      smarter to have a unified way of dealing with it.<br>
    </blockquote>
    <br>
    To be honest, I think the best solution is not to have a screenshot
    protocol at all and implement the solution [1] I described before.
    Hot keys to grab a window's output, screen output or screens output.
    Then, it should be saved to a file (doesn't have to be stored on the
    hdd) and a user-specified application could open the file (by its
    fd), display it to the user and do whatever it wants with it (crop,
    resize, whatever). This way, it is pretty simple for everyone and it
    really follows Wayland's way of being simple and secure.<br>
    <br>
    The video capture API concerns me more.<br>
  </body>
</html>