jussi.laako at linux.intel.com
Fri Apr 11 08:29:15 GMT 2014
On 11.4.2014 2:34, Carsten Haitzler (The Rasterman) wrote:
> it does. in real life.
No it doesn't when I'm configuring the system... ;)
For example, credit card payment terminals have their own keyboards for
entering the PIN code, these input methods and routed to the POS system.
For a reason...
> good luck. you can't. root only can access those. also bypassing the display
Of course I make the particular binary u+s root.
> 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.
You may notice that for example pinentry-gtk/pinentry-qt enforces focus
on window system and you cannot switch the focus away for security reasons.
> perfect example. amazon. don't even need to auth. it keeps your cookies.
> one-click buy.
Luckily, I have that disabled on my account and always logout.
Browser also clears all my cookies every time I close it and certain
cookies are blocked.
> 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.
I don't know why you keep talking about wayland while I'm talking about
_ALL_ service processes in the entire system.
I don't like ALL service processes running at EQUIVALENT privileges.
Where did the least privilege model go?
> 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.
Yeah, I hear that frequently. I don't want to live in that same world... :D
> 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
I am using VirtualBox all the time and I guess many other people are too.
> 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.
I don't have problem with that in regards to Tizen. But I said that all
service processes in the system must not be treated equal. This is not
just about third party apps or apps started through launchers. This is
about every running process of the system, even the ones that are part
of the OS. Because some of those services communicate with external
world, or deal with data coming from external world, so you have to
consider that all those may contain exploitable bugs. Reducing the
possible attack surface with least needed privileges for each process is
just healthy self protection.
For example in case of IVI system, I'd like to minimize possibility of
someone being able to send arbitrary messages on the vehicles CAN bus.
> trying not to it like assuming the kernel is malicious and trying to remove it
> from the picture.
In certain cases kernel may be assumed to be exploitable and in those
cases it is good idea to isolate it on a virtual machine.
> 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.
IF that one GUI app would have rights for modification.
You can have plenty of apps that never use local GUI for anything. You
could build a web server and GUI inside the app and access it remotely.
> 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.
App is not using the blobs, the service across internet is. Practically
it works like this (for example SIM card in your phone):
0) You use desktop computer to make order on Web store using your web
1) Web store sends authentication request to authentication provider
2) Auth provider sends random challenge to your mobile device which
forwards it to smart card
3) You get a PIN code query
4) Smart card encrypts/signs the random challenge with it's encryption key
5) Encrypted challenge is sent back to the auth provider
6) Auth provider verifies the signature
7) Auth provider tells the web store that the user has been authenticated
If you remove the SIM card from your phone, or don't show the NFC credit
card to your phone's reader, display server cannot behave like the SIM
card or NFC credit card would be there.
It can try to auto-enter PIN code, but you would need to know what is
happening outside of the device and know the other related credentials.
If you use the web store from the same device, then it's your fault.
I have two phones, so I would do authentication with the other one.
More information about the Dev