[Dev] Cynara

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Mon Apr 14 12:59:58 GMT 2014

Hello Sorry on lag in answering to list.
I've been working on Cynara's API (that is BTW already published on wiki 
page http://wiki.tizen.org/wiki/Security:Cynara#API_2).

There is only synchronous API designed for libCynara for now. I agree 
that there is a need for asynchronous API and we are going to publish 
one later. For now our priority is to get Cynara working with currently 
published API.
I'll try to answer inline for rest.

W dniu 2014-04-14 11:44, José Bollo pisze:
> On ven, 2014-04-11 at 16:42 +0000, Schaufler, Casey wrote:
>>> -----Original Message-----
>>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of José Bollo
>>> Sent: Friday, April 11, 2014 8:19 AM
>>> To: dev at lists.tizen.org
>>> Cc: Lukasz Wojciechowski
>>> Subject: Re: [Dev] Cynara (filesystem)
> (snip)
>>> 1. The service providers HAVE TO request the security system
>>> ------------------------------------------------------------
>>> What are the service providers?
>>>   - libraries (most probably shared) running in the client process context;
>> No. Libraries are not security elements in a Linux system.
>> There is nothing you can do in a library that you can't do
>> directly in the client code. There is no way for Cynara to tell
>> if the application is lying to it. You can certainly add Cynara
>> calls to a library, but it is pointless because any denial can
>> be circumvented.
> You're right. I wasn't really warned of that, Thanks.
> (snip)
I agree to Casey. We cannot help in case of  library accessed resources. 
Our goal is to provide trusted service (Cynara), that can be used by 
services (implemented as processes not libraries) to check if some pair 
{application + user} is allowed to reach a resource defined by a privilege.
>>>   - What if a malicious application A having accesses to permissions P is
>>> mediating acceses to P for a third application B? That may be the case via
>>> filesystem or via message port when application are sharing a same
>>> certification. It may happen, we have to know that. I don't think that we can
>>> avoid such mechanisms. Any idea?
>> Sorry, you've just hit the security composition problem.
>> To the best of my knowledge no one has a solution.
>> The basic issue is that if you trust Fred with A and Wilma
>> with B you can’t say anything about the safety of A and B
>> when Fred and Wilma are in the same room.
> I have to keep it in mind. Thanks again.
>>>   - What if a service provider doesn't checks the permission it HAVE to check?
>> Then we have a gap in the system. Hey, I think that application level
>> privilege is a really *bad* idea. Alas, you kids seem to think it is the
>> cat's pajamas and have written it into the specifications.
If provider already has access to some resource or is providing some 
service, then it can share it with anyone. Of course it can use Cynara 
to ask if it should, however is completely up to provider what it does. 
We assume that system services are trusted. They work in system domain.
>>>   - As wrote Patrick Ohly, checking permission is a Tizen requirement that have
>>> to deal with upstream projects. Patrick wrote about a stub between Cynara
>>> and Polkit. I think that there is a need to define the process that Tizen will
>>> follow about that point.
>> Cynara isn't the same as polkit and we'd not be doing anyone favors
>> if they start to think it is. I know it is lots of work to create and propagate
>> a new open source project or to maintain patches for our own little thing.
> Agreed.
Yes, we can probably think about it later, after we implement and 
stabilize project.
>>> 2. The filesystem accesses ARE NOT targeted by Cynara
>> Right. They can't be. Cynara uses a different access control
>> model (application/service/resource) than the filesystem
>> (subject/object). There is no direct mapping from one model
>> to the other.
> That would be good to have the feedback of Lukasz about that point.
These are two separate things. Cynara is capable only to check some 
privileges. It does not change SMACK labels, rules. It does not define 
groups etc. It is only responsible for giving simple answer for question 
"is some user running some application allowed to use some privilege?" 
and that all it does. Filesystem control is MAC/DAC responsibility not 
> (snip)
>>>  From what I understand of Cynara, it also defines/uses a launcher. Then I
>>> think that the launcher could configure the filesystem.
>> The launcher only needs to know the Smack label and UID to
>> set on the application. The service gets this information from
>> the IPC mechanism and gets the privilege information from
>> Cynara. It’s the application installer that has to work with Cynara.
> I'm not sure that the UID and the Smack label are enough. More data is
> needed to know what are the privileges of an application.

Cynara needs to know policies in order to properly check privileges when 
asked. Someone has to gave it some. I believe that there will be many 
processes that will need to change set of Cynara policies:
* installer (it reads manifests and knowns what application wants to use 
what privileges)
* privilege-manager (it certainly has to access Cynara policies to make 
some user demand restrictions)
* user adding/removing/managing (every user created has a list of 
applications that [s]he ca run and a set of privileges that [s]he can use)

In Cynara we have two interfaces:
* one for checking privileges - open for everybody (or almost) - 
accessed by libCynara
* second for playing with Cynara policies
The 2nd one should be used only by a trusted application. I believe here 
is a need for a 2nd service to take care a CynaraAdmin role.
Cynara is design to be completely generic. There are no Tizen relations 
in its API. CynaraAdmin service needs to give provide API specific to 
Tizen distribution taht will be used for:
* managing policies
* managing users
* application installation processes
* application launchers
It shall be an extended service version of current libprivilege-control 
API. This will be Tizen specific.
It will be responsible for setting SMACK labels on directories and files 
during installation, proper privileges dropping (setuid, etc) during 
application launch
and among all these things it will also set proper policy rules in Cynara.

@Jose: Why do You think that SMACK label user's UID and privilege name 
are not enough to check access? Maybe You can provide an example?

>>> I proposed a smack aware launcher that(**see post scriptum**):
>>>   - restricts the the smack accesses of the launched applications depending on
>>> their permission
>>>   - restricts the filesystem accesses of the launched applications depending on
>>> their permission
>> We'll certainly look more at this proposal.
> Great! Let me insist here on the fact that this solution let the kernel
> check all filesystem accesses with no time overhead. Besides, it allows
> to make redirections depending of the possibilities of the platform for
> removable media and the support of multi-users.
>>>  From my experiments, adapting the filesystem to the need of the security is
>>> taking only little time, less than 1ms (I didn't tried on ARM). Then why to not
>>> add it to Cynara, its specifications, its API? Agreed?
>> Cynara isn't in the launcher. It's in the installer and services.
> Yes, it's a whole. But without a launch step, my filesystem control
> mechanism would not work.
Launching code should be used by launcher. It is out of Cynara's scope.
> Best regards
> José
Best regards

More information about the Dev mailing list