> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa > Sent: Thursday, April 24, 2014 10:09 AM > To: [email protected] > Subject: Re: [Dev] How to share files with Cynara > > On 2014-04-22 18:26, Schaufler, Casey wrote: > >> -----Original Message----- > >> From: José Bollo [mailto:[email protected]] > >> Sent: Tuesday, April 22, 2014 8:37 AM > >> To: Schaufler, Casey > >> Cc: [email protected] > >> Subject: Re: [Dev] How to share files with Cynara > >> > >> On mar, 2014-04-22 at 14:36 +0000, Schaufler, Casey wrote: > >>>> -----Original Message----- > >>>> From: Dev [mailto:[email protected]] On Behalf Of José > Bollo > >>>> Sent: Tuesday, April 22, 2014 7:07 AM > >>>> To: [email protected] > >>>> Subject: [Dev] How to share files with Cynara > >>>> > >>>> Hi all, > >>>> > >>>> I submit you some use cases of file sharing between applications. Can > >>>> you please explain how to handle it with Cynara. > >>> Alas, we are required to have places where all applications can > >>> share files with impunity. No privilege required. > >> Making applications collaborating isn't so bad;) > >> > >> How will the files be labeled? (security.SMACK64) > >> - User::App::???? > >> - User > > Caveat: This should be considered design discussion. > > While I will attempt to sound authoritative, there is > > plenty of room for disagreement, improvement and > > correction. > > > > We have more than one sort of sharing to address: > > 1. Removable media > > 2. Shared by everyone always > > 3. Shared among all "privileged" applications > > 4. Shared among a specific set of applications > > > > Case 1 is easy. > > We mount the media with an unlabeled filesystem type > > (FAT) with smackfsdefault='*',smackfsroot='*' and we're done. > > Is such permissive configuration really desired? Maybe it should be > controlled by a separate privilege and enforced by DAC?
Sorry, but this is a requirement. For better or worse. > > Case 2 is also easy, but not quite so simple nor so pretty. > > Create a directory $HOME/tmp (for example). Label it User::App::Tmp > > and mark it transmuting. When an application is installed a Smack rule > > has to be added to allow it access: "AppLabel User::App::Tmp rwxat". > > > > Case 3 is similar. > > Create a directory $HOME/managed (for example). > > Label it User::App::Managed and mark it transmuting. > > When an application is granted the privilege add a Smack rule > > to allow it access: "AppLabel User::App::Managed rwxat". > > When the application is disallowed the privilege change the > > rule to "AppLabel User::App::Managed -". > > This would be the case discussed previously, about privileges to directly > accessed resources. It works only when permission has the same setting for > all users, not when multiple users can have different permission > configuration. But we can have the rule always on (to get transmuting > behavior) and > limit access by DAC. Recall that Cynara knows both the Smack label and the UID of the application process. For application enforced privilege we're fine if the user has a different set of privileges than the application. > > Case 4 is like case 3, except for how to decide which applications > > are given access to the directory. This is left as an exercise for > > the reader. > > In Tizen 2 libprivilege-control had support for such feature. It was quite > ugly > and wouldn't scale for multi-user. It used a base64 of a hash of an author > certificate as Smack label for directory and added a rule for all > applications. > For OSP, every application exported a directory "shared/trust", > under its private directory. > > But no matter how we do it, supporting this functionality would lead to > custom Smack labels for application groups and custom Smack rules for such > applications. Things will be much simpler if we don't go that road. > > > If we want to make applications from all users share data we > > can put the data in /opt/apps instead of $HOME. > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
