On 2014-04-09 09:30, Patrick Ohly wrote: > Access control: I understand that a service will have to implement this > access control mechanism and I see how Cynara will help with this. What > hasn't become clear to me is how a service running as a normal user > process (same PID as all other apps of the user) will be able to protect > its data files from those other processes when using the 3-domain Smack > model.
One assumption for Smack is needed for this model to work: to assign separate Smack labels for the applications. I believe that there is a consensus to go that way. While different, the app labels would still logically belong to the User domain. This is probably very confusing, given the "3-domain policy" name, but a domain is defined as a set of labels. Separate Smack labels offer two important benefits: - separation: keeping private application files private, hidden from other apps. This also prevents stuff like ptrace() between applications with different privileges. - identification: whether a service consults Cynara for policy or implements some policing on itself, it must be sure who is on the other side. Smack label is a perfect unforgeable identifier for user apps. > Will it be possible to write services that grant direct > read-only access to files (for performance reasons) while handling > writes in the service? We could imagine a service that opens a file read only and sends it's file descriptor to the application. But Smack won't allow this to happen unless the application has read permissions to the file. There probably is no work around for that, making impossible to grant direct access to protected files.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
