[Dev] Cynara

Carsten Haitzler c.haitzler at samsung.com
Fri Apr 11 09:53:20 GMT 2014

On 04/11/2014 05:29 PM, Jussi Laako wrote:
> 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... ;)

do you use linux? X11? do you even intend to use wayland?

> 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.

so you throw out all the security giving unabridged access to this app.
so youi fully trust this app to not just blast over /dev/mem or
/dev/kmem or add backdoors into your kernel or libc, but you can't trust
a display server that is shipped with the os (kernel and more)? i smell
a bit of a double standard here.

>> 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.

and all that input goes through the display server. x11 supports xinput
to allow clients to see things.. like multitouch devices and mroe
advanced devices. one of these days try:

  xinput list

then find your virtual core keyboard device (with id next to it)

  xinput test-xi2 <DEVID>

and then keep that going while you have one of these secure pin entry
apps that use xgrabkeyboard (xterm secure mode is one for example).

surprise. every key you press appears despite your notion that this is
"secure". trust me. x11 is not secure in the slightest. if you have
access to the display server as a client, it's game over. your world
belongs to the app that has access.

and the DISPLAY SERVER still sees all these events. it's xorg. do you
trust it? you obviously seem to have no problem trusting it right now,
and it has full access. if xorg were malicious - same as weston or any
wayland compositor, you'd be totally out of luck. i seem to be repeating

>> 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.

but 99% of peolpe don't. what you do in your locale area is not what 99%
of users do. the point remains - that for users, in general, if the
display server is compromised and/or malicious, you are screwed. it's a
false sense of security to think otherwise. and like it or not the
display systems in tizen are x11 and in future wayland (iv using wayland
now) and neither work the way you would like them to and neither WILL
work the way you want them to because they have to work this way for
many reasons which i have been trying to explain, and for one major
reason above all - compatibility.

> 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.

because you replied to my mail that mentioend that weston (wayland
display server) would have access to pim data regardless of security
measures as long as some app could read the data and display it (which
there will be) and/or write to it. weston was sepcifically mentioned in
the original mail.

> 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

then you'll have to make your own os and display system as that is not
how the ones we have work.

>> 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.

i deal with production issues in making products regularly and have done
so for many years. a few ms of latency is a production issue BUG that
halts the release of a product. that is how important latency and
performance is. every level of abstraction costs more power and people
spend weeks tyring to save a few percent on power budgets in tests, and
that without these, products again don't ship.

>> 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

you indicated this at many occasions. that is the whole topic of this
thread. i've never digressed from discussing the display server, and
this is the tizen dev mailing list... :)

> 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):

for a smart card, the data is presented to userspace, it is not
magically transmitted over the internet

> 0) You use desktop computer to make order on Web store using your web
> store crendetials
> 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

you have created a very specific case where the modem tsalks directly to
the smart card and the modem provides networking. in the general case of
a smart card, you would need to read the data and send it via a tcp etc.
socket via whatever networking means your os supports, and the
routing/destination would be handled by the app.

> See http://www.mobiilivarmenne.fi/en/#mika
> 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.
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140411/e08ea164/attachment.asc>

More information about the Dev mailing list