> -----Original Message----- > From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of José Bollo > Sent: Friday, April 11, 2014 8:19 AM > To: dev@lists.tizen.org > Cc: Lukasz Wojciechowski > Subject: Re: [Dev] Cynara (filesystem) > > On mar, 2014-04-08 at 20:57 +0200, Lukasz Wojciechowski wrote: > > Services that are being used by applications need to control if the > > caller has sufficient privileges to call each API. In Tizen 2.2.X this > > level of access control was done using very detailed Smack policy on > > IPC mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack > > policy, there is a need for user-space mechanism that complements the > > solution. This is a place for new module - Cynara. > > > > Details can be found at wiki page: > > http://wiki.tizen.org/wiki/Security:Cynara > > > > Page is still being constructed, but is is high time to share and > > probably start a discussion. > > I will be glad to answer any questions about it. > > I plan to publish roadmap for Cynara development and API draft this week. > > Hi Lukasz, Hi Gagarin, Hi all, > > I want to come back on the main topic. > > The proposal Cynara is IMHO going the good way. But I have at least two > remarks: > 1. the service providers HAVE TO request the security system; 2. the > filesystem accesses ARE NOT targeted by Cynara. > > 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. > - Unix socket domain services; Yes, programs that provide services over UDS are supported. > - DBUS services. Yes, programs that provide services over dbus are supported. > In all this cases, the service is able to retrieve the client PID. That is > what is > detailed here > https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials > > That PID is used to check the permissions using some library. > > For me that is good enough and we can go on with that. (That is really better > than trusting clients to check for there permissions;) But: > > - 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. > - 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. > - 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. > > 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. > ----------------------------------------------------- > > Here again, Patrick was the first to point it out. OK, but it is not news. It is a well understood aspect of the application privilege model. > That is a real important point specially for native applications (if natives > or > hybrid applications are still in the scope) because libc doesn't check that a > open is allowed and it will never do that. <payattentionbecauseIamtiredofsayingthis> Libraries are part of the application and are not security enforcing components in Linux. They can't be. They can always be circumvented. </payattentionbecauseIamtiredofsayingthis> User installed native applications are not supported in Tizen. > Smack ensures the system integrity/security and is the backbone of security > but it can't go into the details of all the permissions. It shouldn't also > pollute > the file system with tons of labels, making it difficult to admin without > super > powers. Right. > Then now, the biggest problem isn't the security but the PRIVACY. To ensure > it, there is a need to restrict the accesses to the filesystem of the > applications, depending on their permissions: > - any application has access to system parts of the filesystem (here > restrictions are set using DAC and sMACk) > - some applications will only see their data > - some application will see their data and some data shared on a certificate > base > - some application will have access to shared data of the user > - some application will have access to all data of the user > - some application will have access to all shared data of all users > - ... > - some application will have full access to the filesystem > > 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 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. > 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. > Best regards > José > > post-scriptum: The last version of smaunch (proof of concept) now integrate > keyzen the manager of permission keys (proof of concept). > Taking smaunch and keyzen together is implementing a kind of cynara (yes it > really look like and it really works but is a proof of concept). > Details will follow. If curious, check https://github.com/jobol/keyzen and > https://github.com/jobol/smaunch > > > > > > > > _______________________________________________ > Dev mailing list > Dev@lists.tizen.org > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
