Carsten Haitzler (The Rasterman)
tizen at rasterman.com
Thu Apr 10 23:34:47 GMT 2014
On Thu, 10 Apr 2014 17:39:38 +0300 Jussi Laako <jussi.laako at linux.intel.com>
> On 10.4.2014 15:16, Carsten Haitzler (The Rasterman) wrote:
> > display server can driver the app and all auth the same way a user can.
> Only in case display server has access to all the input methods used by
> the app.
it does. in real life.
> > it has all access to 1 just as much as the user does. if a smart card is
> > plugged in, then all the callend.veryfy, if it involes a user, goes through
> > the display server (pin number, password, etc. etc.) and display server can
> > have recorded such responses before.
> Of course I would read the PIN straight from keyboard and disable
> display server's access to that piece of hardware for the duration of
> PIN entry.
good luck. you can't. root only can access those. also bypassing the display
server bypasses focus management and policy. even if you had root access, if
the display server has decided your app is not to be shown right now because
some other dialog/app is more important and deserves to be seen/focused (this
happens a LOT), then you would suddenly stop all input from working - a user
couldn't type or interact with the app they currently see. they cant switch
desktops. an app that does this would be shunned by users and ultimately booted
from an ecosystem because it is malicious in terms of usability.
> > here's a great trick. you auth with your bank app. you select transfer,
> > amount then destination. let's say just when you click "ok" on screen the
> > display server rapdily click son the bank account number and alters it and
> > THEN hands on your press to ok. now it just changed the destination of the
> > transfer. if a user can do it, the display server can do it.
> That's why we here have heuristics at bank side that detect suspicious
> patterns on larger transfer amounts and require separate external
> verification using another device. And you cannot accept ANY payment
> with just point-click, all payments are approved using OTP lists on paper.
perfect example. amazon. don't even need to auth. it keeps your cookies.
one-click buy. that would be a breeze to cause a user to buy things they din't
want to. every step you take to make things harder for a user in the name of
security, discourages them from doing that action. amazon and other retailers,
do their utmost to encourage interaction - that's their job. they won't do
this. a malicious display server can launch a browser, go to a website, log in
given a known login/password or rely on the user to stay logged in (vast
majority of people would do this), and then make purchases. it could go to
gmail and start mailing all your contacts embarrassing things.
i repeat. the display server is a trusted part of the system. in a wayland
world, display server includes policy and desktop (focus policies, virtual
desktop policies, etc. - ie window manager). do not dismiss it as incapable of
foiling your magic security mechanisms. it can and if malicious, will.
> You would get caught in no time as owner of target account for any such
> attempt anyway.
> > you still then need a system compositor. another display server. another
> > process you have to trust and can be exploited. like a kernel. nothing
> > different.
> Yes, this way I can bound and review the amount of code to be trusted
> and sandbox the untrusted part. So I can even discard all NIH stuff. And
> no, I need to trust only those small parts of my own, nothing outside.
> And I of course would make sure input methods and rendering are NOT
> handled by the same process ever. I could even have a randomly
> self-modifying code running for each keyboard key separately.
they have to be for routing. and go read wayland and x11 protcol. you don't
live in the same world as the rest of us. in the real world input goes
via the display server. it has to. and my point stands. if it is malicious...
you're in trouble. display servers use opengl to accelerate rendering and
effects. on the vast majority of embedded hardware platforms that means you
depends on a binary blob you can never audit. it's also very large. this is
also the case for all applictions using opengl to render. they are all now
compromisable by the gl driver blob.
> > and your bugfix or security update for the display server then makes your
> > apps cease to run. happy users indeed. and as above. if you compromise the
> > display server as it runs - in memory, a malicious attack can lurk unseen.
> Malicious applications wouldn't have access to the same display server
> as trusted ones. Maybe not even to the same CPU/GPU hardware. You could
> even use mechanical switch to switch between two GPUs.
in the real world they will be using the same gpu. in the real world a double
compositor setup is something that will not be shipped because of the extra
latency and power costs (all input has to now bounce through system compositor
to session compositor and then to app, and output in reverse). it involves more
context switching and process wakeups.
> > it doesn't mean that a shared point of data flow - be that kernel, or
> > display server, doesn't have full access to everything. the original remaek
> > ( i don't want weston to have access to my pim". if it chooses to be
> > malicious, it'll have all the access it likes. if the kernel is compromised
> > you are also up the creek without a paddle.
> Smaller the amount of code that is exposed this way, more secure it can be.
see above. opengl.
> Using possibility of a kernel bug as excuse to grant wild card access
> for all applications to all data in the system is not acceptable.
no - i never said that. i never said to grant wild access. i did say that the
display server is a trusted part of the system, and you need to accept that.
trying not to it like assuming the kernel is malicious and trying to remove it
from the picture.
> syncEvolution doesn't use display server for anything. So you can make
> client GUI to be read-only on PIM data and display server is going to
> have hard time trying to modify the data.
as per the mail i replied to... if an app has access it can access your pim
data as much as that app can. if that included modification (which it will for
at least one app) then the display server can modify too.
> For something like smart cards, kernel cannot do MIM any more than you
> can do with SSL connections. It just transports encrypted blobs.
which is irrelevant. if the smart card is plugged in then the display server or
kernel can drive the app that is using the smart card encyprted blobs as if the
user were driving it.
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
More information about the Dev