On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote: > On Wed, 2014-04-09 at 12:27 +0200, José Bollo wrote: > > On mer, 2014-04-09 at 09:30 +0200, 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. Can someone point me towards documentation for that, ideally with > > > an example? Will it be possible to write services that grant direct > > > read-only access to files (for performance reasons) while handling > > > writes in the service? > > > > I really agree with that remark. That is why I proposed a launcher that > > is aware of the problem of sharing/not sharing the filesystem. > > (see https://lists.tizen.org/pipermail/dev/2014-April/002292.html) > > I think that because smack rules modification will become lighter, the > > launch time will be less than 1 ms. > > I've seen that. With that approach, apps can be restricted, but process > not getting that treatment would still have full access to everything. I > wonder whether we can do better than that.
You are right: apps not launched, not receiving the treatment have full accesses. But to my eyes it is not a problem because: - Tizen enforces the use of launcher (for security) so what are the applications that aren't launched? - DAC and MAC are still here filtering real intrusions - the policy for the user will be applied anyway - there is a need for full access (a file browser for exemple, developper tools) - why to disable something that would be enabled after validation (okay malicious code but config let you choose to automatically accept keys) - letting someone scrunch its own data is a freedom act - in worst case, a binfmt stuff could enforce launcher > Regarding the launcher, does it still grant the restricted app access to > the system and session D-Bus? Can it reduce access rights for files > and/or directories from "read/write" to just "read"? That would be > important for the "fast read-only access, secure and controlled write" > use case. Yes the launcher allow to hide parts, to make read-only other parts and to grant read/write accesses to other part. Any combination is possible, the given example is: - /home -- dont see any other user +rw /home/%user/.config/%appid -- access to config +r /home/%user/share -- shared data +rw /home/%user/share/%appid -- own shared data +rw /home/%user/share/.cert/%cert -- same certificate What means that no other user home is visible (- /home), no data of the user are visibles except the config directory of the application (r/w), the data shared by applications, read only except for owned data and data sharing the same certificate. > > > API + upstream: getting patches depending on Cynara into upstream > > > projects might be hard, depending on the project and how tolerant they > > > are of ifdefs. Would it be possible to provide a compat layer that acts > > > like Polkit but underneath calls Cynara? It doesn't have to be ABI > > > compatible to the GObject API, some limited API compatibility might be > > > good enough to get upstream code compiled on Tizen. > > > > That is a good idea. Can you estimate how hard it will be? I'm afraid > > that it could be complicated. > > I've no idea. I'm just bringing it up as a wish-list item ;-} > > > > Cynara API: you mention a single API function. Will that be synchronous > > > or asynchronous? If synchronous, how are services expected to remain > > > responsive will a policy check runs? Multithreading? My main concern is > > > a policy check which involves the authentication agent and thus user > > > interaction; normal policy checks probably will be fast (but still...). > > > > IMHO it should block and be "as if mono thread". It would simplify the > > development process of the library, leaving details of multi-threading > > to the integrator. It would be very painful to launch a thread to wait > > some answer or to provide a file descriptor for the glib loop, the qt > > loop, the ??? loop .... > > Isn't glib the de-facto common standard? Qt on desktops is compiled with > glib integration support. I've seen that EFL also has code for it. I > don't know how either of these get compiled for Tizen, though. Agreed halas. But I saw in https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials that dbus over libdbus, kdbus and 0MQ are also targeted. > Regarding "leaving details of multi-threading to the integrator": that > may simplify the work for the lib developer, but it complicates the > usage of the lib for service developers, in particular if those services > are not yet multithreaded. Just saying. Agreed too. But remember only if it doesn't want to block. Best regards José _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
