[Dev] How to share files with Cynara
casey.schaufler at intel.com
Thu Apr 24 19:54:49 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Rafal Krypa
> Sent: Thursday, April 24, 2014 10:09 AM
> To: dev at lists.tizen.org
> Subject: Re: [Dev] How to share files with Cynara
> On 2014-04-22 18:26, Schaufler, Casey wrote:
> >> -----Original Message-----
> >> From: José Bollo [mailto:jose.bollo at open.eurogiciel.org]
> >> Sent: Tuesday, April 22, 2014 8:37 AM
> >> To: Schaufler, Casey
> >> Cc: dev at lists.tizen.org
> >> 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:dev-bounces at lists.tizen.org] On Behalf Of José
> >>>> Sent: Tuesday, April 22, 2014 7:07 AM
> >>>> To: dev at lists.tizen.org
> >>>> 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
> Dev at lists.tizen.org
More information about the Dev