[Dev] Cynara

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Sat Apr 12 03:14:49 GMT 2014

On Fri, 11 Apr 2014 15:34:42 +0300 Jussi Laako <jussi.laako at linux.intel.com>

> On 11.4.2014 12:53, Carsten Haitzler wrote:
> > do you use linux? X11? do you even intend to use wayland?
> Yes, but I also know how to modify it and not let X11 access certain 
> input devices. I don't have any plans for wayland, maybe once it matures.

you use x11... you're screwed. see my xinput example. your keyboard is
sniffable by any client, should they desire, regardless of "secure grabs".

> > 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.
> Of course! Display server is NIH! And you just said it's malicious, I 
> don't trust purposefully malicious applications.

so you don't care about security and isolation. you are happy to give one app
total free reign, yet not a display server. you just are biased for the app you
like and against the app you don't know (and that is necessary for the system
to work and is designed by people with far more experience in the field). so
that basically makes everything you say pretty pointless as it doesn't see
things from an even viewport or even a practical standpoint. so you allow ONE
APP full root access to do whatever it likes - yet a display server running as
non-root with more limited access is a big evel thing to be designed away into

> I want to decide component by component. I switched over to Debian 
> because I don't trust systemd (it screwed up two of my openSUSE 
> installations).

if display server is not malicious, then why would you care if it has access
to all your input and display output? why then at all go to insane efforts to
split etc. that is basically unmaintainable (thats what has happened to x11)?
if its trusted then leave it alone. just remember if its compromised - just
like kernel (libc etc.) anything within its view space is compromised too.

> > 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
> I know, that's besides the point. But that's one of the X11 security flaws.

yes you claim that this grab thing is secure. so your idea of secirty is rather

> > but 99% of peolpe don't. what you do in your locale area is not what 99%
> > of users do.
> 1% of the world population is A LOT of people. I'm one of the people who 
> are interested on products like:
> http://www.blackphone.ch

i was using numbers as illustration, not as absolute truths.

> > 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.
> It was mentioned as an example, but I think the point behind the message 
> was to refer to any OS services running on the system.

no. i was specifically tar getting weston because i know what is has access to
and it is not isolated. it's a conduit through with pretty much all input and
output happens for a user. thus it sees all of this. if this app is something
you want to isolate like your tetris game etc. then you need to be made aware
of the reality that it is not tetris game, or a pim manager. it's a core system
component as much as kernel, libs, pulseaudio etc. are and that as a result has
far more access.

> > then you'll have to make your own os and display system as that is not
> > how the ones we have work.
> More like make my own distro, but that's what I'm already doing using 
> Yocto. I get quite many things I want with Qt Embedded.
> > 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.
> Well, Android and WP both have practically virtualization through the 
> runtime. For example UML is just another way.
> > you indicated this at many occasions. that is the whole topic of this
> > thread. i've never digressed from discussing the display server, and
> No, topic of the thread is Cynara and access control of native OS 
> services. Display server was just mentioned as one example of such.

and display server is not something you use cynara for - it isn't accessing pim
directly. it's not trying to make calls via the telephony daemon. it's acessing
display, gpu and input devices and listening for client socket connections that
go directly to it - like clients talk directly to cynara daemon or buxton or
pulse audio etc. changing this breaks protcol and compatibility.

> > for a smart card, the data is presented to userspace, it is not
> > magically transmitted over the internet
> But for that userspace as well it is just encrypted blob. It is 
> understandable only to the smart card internals and to the service on 
> the other edge of internet.

and so to ask the user for a passowrd or challenge.. the display server drives
the app tells it to do its thing, when password is requested display server
fakes a previously saved one and app does what it is meant to do, but not
driven by user.

> > 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.
> It doesn't matter for the case if it's modem or if the modem is just 
> software running on APE, or if it's something else in normal user space 
> Linux. Modem is just a piece of software like everything else on the 
> system. With LTE it is more or less just an IP data pipe.
> http://en.wikipedia.org/wiki/Subscriber_identity_module#Authentication_key_.28Ki.29
> You cannot forge this challenge-response handshake unless you can 
> extract the key from SIM card.

you force the app to do it as the user would. click buttons and enter text
(passwords or whatever).

> In the original SSO implementation we used SIM's authentication engine 
> to generate data encryption keys, this handshake doesn't go through the 
> display server. And display server nor the PIN code application doesn't 
> have access to the SIM API, it can only respond to the PIN request WHEN 
> initiated by the SIM card. We just used our own N pieces of our own RAND 
> and the resulting SRES' was basis for the encryption key.
> RAND-SRES handshake is between UI-less daemon and the SIM card. PIN code 
> GUI is completely separate from this process. Even if your display 
> manager knows PIN code, it also need to know RAND in order to construct 
> same key.
> There is also EAP-SIM for WLAN and such, see:
> http://tools.ietf.org/html/rfc4186
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

Carsten Haitzler (The Rasterman) <tizen at rasterman.com>

More information about the Dev mailing list