Authorized clients

[Martin Peres]

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 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 hope I made my case :)

Cheers,
Martin