[Dev] Cynara

Jussi Laako jussi.laako at linux.intel.com
Thu Apr 10 14:39:38 GMT 2014


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.



More information about the Dev mailing list