On 2014-04-16 09:13, Patrick Ohly wrote: > On Tue, 2014-04-15 at 18:33 +0200, Rafał Krypa wrote: >> *Smack policy for applications* >> Each application will be run with a separate label, belonging to the >> User domain. Label will be based on package id and allocated during >> installation. Suggested template for application label is >> "User::Application::$PKG_ID". >> Each application label will be given the same set of Smack rules, >> based on a template. These rules should allow applications to contact >> with services for accessing sensitive resources, but prevent direct >> access to these resources. Services will run with either "System" or >> "User" label, so >> applications will be given write permission to these labels. > Just to clarify, "write permission" means "can send messages to a > service via a unix domain socket" but not "write arbitrary data into > files with the User label"?
I agree with you that it's not intuitive. I have learned about this only recently from Casey. > How does that work? Probably Casey could explain this better, but my understanding of the idea is as follows: While the file is being opened, regardless of the access mode, opening process will have to access it's inode. Since this means reading inode contents, LSM hook for inode access should check if the calling process can read the inode. So opening a file, even in O_WRONLY mode, would require having both read and write permissions to the file. > In my (admittedly limited) understanding of SMACK, > if both socket and normal file have the "User" label and there is a > SMACK rule that grants write access to that label, it'll apply to both > socket and files. Not what we want, is it? It turns out that your understanding is currently right. I have tested it some time ago and read access is not required. Casey says it's a bug, so we can still rely on this when the kernel is patched. > How will the app receive the reply if it can't read from the "User" > domain? My guess is that this works because the data that it needs to > read was explicitly written to by a service in the "User" domain, but I > am not sure. Communication over UDS requires only write permissions. The client (connecting side) needs write access to the server. The server should also require write access to the client. The latter was found missing is Smack as well, but it's already patched (not backported to Tizen kernel yet). _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
