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 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.
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.
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.
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.
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.
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.
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.
For something like smart cards, kernel cannot do MIM any more than you
can do with SSL connections. It just transports encrypted blobs.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
