On 09/01/2014 22:16, Jasper St. Pierre wrote:
On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres <[email protected]
<mailto:[email protected]>> 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.
No probs. I understand. We'll need to make a recap email soon :)
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 <http://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
Ask yourself, trusted by whom?
You are partly right, the protocol should kind of be agnostic of the way
the authentication works. On the other hand, I'm kind of leaning towards
thinking the screenshot protocol almost shouldn't exist (the solution
[1] I talked about before). However, we'll need a video capture protocol
and I think we all agree on how to handle the authentication on this one
because we just can't limit the number of captures :D
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 :)
The NSA may find a way, but when a script kiddy can do it, then there is
obviously something wrong. So, unless you are the kind of guys who
authenticate over the internet without SSL, then you need to revise your
judgement on that ;)
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.
See, we agree on almost everything. The only thing we disagree about it
the "trusted" label. At first, you trust the app, but then, there is a
new version that allows disabling the visual cues and settings are
stored in a file owned by the user. Then an attacker simply has to
change the settings, run the app in the background and get the images.
So, as I said, I don't trust application developers for doing the right
things!
You'll say it is the same problem for the video protocol, but the
difference is we don't have a choice.
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.
If the user doesn't want the screenshot, the app won't get the
screenshot. How is this broken?
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.
That's the idea. I haven't read the paper yet, but I know it is much
more than that.
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.
Yep, but this is out of scope. The thread is already long-enough.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
