[Dev] Cynara (filesystem)

José Bollo jose.bollo at open.eurogiciel.org
Mon Apr 14 09:44:35 GMT 2014


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)

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

ACK

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

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

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

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

Best regards
José




More information about the Dev mailing list