Hello everyone.
I have an impression that discussion went some wrong place. Is this
thread still about Cynara?
I'll try to answer inline to Cynara related questions. Please feel free
to start new threads on other topics. ;)
W dniu 2014-04-11 01:21, Carsten Haitzler (The Rasterman) pisze:
On Thu, 10 Apr 2014 16:06:36 +0000 "Schaufler, Casey"
<[email protected]> said:
-----Original Message-----
From: Patrick Ohly [mailto:[email protected]]
Sent: Thursday, April 10, 2014 2:05 AM
To: Schaufler, Casey
Cc: José Bollo; [email protected]; Lukasz Wojciechowski
Subject: Re: [Dev] Cynara
On Wed, 2014-04-09 at 16:34 +0000, Schaufler, Casey wrote:
On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
You are right: apps not launched, not receiving the treatment have
full accesses. But to my eyes it is not a problem because:
- Tizen enforces the use of launcher (for security) so what are the
applications that aren't launched?
Which Tizen profile do you refer to here?
In Tizen IVI there are several user processes which do not get spawned
by
the launcher and thus have access to more data than they really need.
Those are mostly services (weston, murphyd) and basic
UI applications (weekeyboard). Everything on Tizen (true
for Android, too BTW) has access to more data than it needs.
The question is whether it has access to data that matters.
Who cares if it can read /etc/tizen-release?
I guess it depends on the data and the goals. I'd certainly would be
more comfortable with a Tizen device where Weston, murphyd and
weekeyboard can't read or (worse) write my PIM data.
What is "PIM data"?
You are already trusting weekeyboard with your passwords
and weston with everything you display. If no one is making sure
that these programs are worthy of trust we have much bigger
problems than murphyd getting an accidental peek at your
"PIM data".
yup. that was my point. there is a level of trust placed in such core
apps/servers/tools - like we trust the kernel, or systemd, glibc etc. not to be
malicious. it means that any bug in such core services should be taken
seriously and fixed (bugs that could lead to compromising the functionality
and turning a friendly tool into a malicious one).
there is no point having some false sense of security.
Cynara can be used for privilege checking by services. Service is a
process that can directly access some resource. If service wants to
constrain access to provided resources it can ask Cynara as trusted
service. If we want to restrict access to some resource:
1. access should be provided by a service not by a library
2. service should ask Cynara every time before granting access for some
application
Whether it's worth investing extra effort is up to the people defining
the product and its requirements.
We have to live within the security budget. That means we can't
fix everything that's broken, we can't replace everything that's
hopelessly broken and we can't wrap everything with a protective
layer of magic that prevents good programs from doing bad things.
We can take steps, and isolating user installed applications is much
more important than anything else. Assuring that weekeyboard
and murphyd have absolutely minimal mutual access is just not
cost effective.
- DAC and MAC are still here filtering real intrusions
But that doesn't help when the uid and smack label are the same.
Regarding "leaving details of multi-threading to the integrator":
that may simplify the work for the lib developer, but it complicates
the usage of the lib for service developers, in particular if those
services are not yet multithreaded. Just saying.
Agreed too. But remember only if it doesn't want to block.
My expectation is that services will not be allowed to block. So either
they
are multithreaded, asynchronous or both. Cynara as currently designed
does
not fit into services which are asynchronous, but not multithreaded.
Do we have services that are asynchronous, but not multithreaded?
I'm all in favor of generality, but I don't believe in solving problems
that we don't have.
As Jussi said, at least in the glib-based world, asynchronous without
multithreading is the preferred model. If you need a specific example:
syncevo-dbus-service, implementing the PIM Manager API in IVI, is not
multithreaded.
OK, great, thank you. (Grumble)
For now we want to set up working Cynara ASAP. That is why there is only
synchronous API available. However I agree that there is a great need
for asynchronous API.
We do plan to provide one.
There's one more related issue with having a single blocking API
function: suppose a service did create a thread to invoke that API and
then while the check still runs needs to shut down cleanly, or (perhaps
more realistic) the client asking for the restricted operation quits. A
service must be prepared for this, even if it is only in the error
handling paths. Can the service cancel the running call into Cynara?
If it can't then it can only kill the thread, without knowing in which
state that thread is.
Cynara also needs to be thread-safe itself internally, of course.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
Best regards
Lukasz
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
