Authorized clients

[Jasper St. Pierre]

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


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

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

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 :)


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


Of course not. It would be bad if somebody managed to repeatedly call the
trusted screenshot application to silently dump it somewhere. A
well-designed screenshot application shouldn't silently take a screenshot
and put it on the clipboard -- it would flash the screen, make a camera
noise, and maybe bring up a dialog for where to save it to. I'd imagine
that some people might build "take a screenshot silently" scripts for their
convenience, but if they want this I feel that they have to deal with the
consequences.

Apps on Android don't have this problem because there's a very limited API
to interact with other apps. I'd love this too, but I feel like the
Linux-using crowd wouldn't.

Again, I don't feel it's the compositor's responsibility to protect the
user from trusted apps.

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

So, in the most common case, the app breaks. If the user clicked on the
"Take Screenshot" button, and then picks a button from the prompt at
random, they get a broken app 50% of the time when they wanted to take a
screenshot. I'd say this isn't a worthwhile user experience.


> 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 point discussing it in here. If you
> want to discuss about it, we are a group of 3 security engineers and one is
> doing his PhD on usable security. You may be interested in joining us (if
> that's ok with the others).
>
> If we manage to make an implementation of UDAC in wayland, then we would
> be able to implement a screenshot application like you wished to have.
> However, it won't be portable and will basically be an equivalent to the
> compositor running an application with a custom protocol to request
> whatever screenshot it wants.
>
> Without those secure widget, the compositor doesn't know that a click on
> the mouse at this position actually means "take a screenshot".
>

I tried to Google for "UDAC" and "UDAC security", but couldn't find
anything about this. This sounds to me a bit like Portals -- instead of
giving the app free roam to browse the user's documents, the app asks the
OS to let the user pick a file from its documents, and gets passed back
file contents. Apps can't access the user's sensitive data directly by
scanning, only the files that the user chooses to share.

I'd hope that we'd be able to have such technology with Wayland, given how
it's technology we're working on for application sandboxing, and half the
reason kdbus is being developed.


> I hope I made my case :)
>
> Cheers,
> Martin
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140109/ebf937c2/attachment-0001.html>