Passing file descriptors is a mechanism by which one process can pass its access rights to another. Because the decision to pass these access rights is made by the process itself it is considered to be a part of the discretionary access control (DAC) policy, just like setting the mode on a file. The system assumes that the process isn't going to pass file descriptors open on files that it does not want to give the receiver access to. This is very much like the policy on IP domain IPC, where it is assumed that if you care who you're talking to you will take precautions to ensure you're talking with someone you want to.
In a mandatory access control (MAC) environment you can still pass file descriptors, but doing so is constrained by the mandatory access control policy. Unlike DAC policies, MAC policies don't trust applications to make their own decisions about what communications are appropriate. Processes are not allowed to change the MAC information on files, even if the user owns the file. Similarly, a process can't give its access rights to another process if the MAC policy does not allow the receiver those rights. Tizen uses the Smack LSM to provide MAC enforcement. When a process receives a file descriptor from another process a check is made to ensure that the receiving processes has the access that the file descriptor would grant. If it does not, the transfer of access rights fails. If the two processes are in the same domain, the transfer will succeed. If the two processes only have write access (for example, one is in the System domain and the other is in the User domain) to each other they can try to pass descriptors, but if the descriptor provides read access to a file that the receiver can't read the transfer will fail. Programs should not be sharing their private data with other programs. For the Smack perspective the right thing to do is to label data that is shared between domains as shared data. If a process in the System domain wants to pass a file descriptor to a process in the User domain the file should be labeled System::Shared if the receiving process is given only read access to the file, or System::Run if it is being given read and write access. The file should be maintained with this label by the owning process. The difference between domain private data and data shared between domains is very important to system security and critical to privacy. Programs and services should never share data that they don't know to be appropriate for all of the domains they are sharing it with. Data that is being shared outside of a domain is not private data and it should be clearly labeled as shared data. It is much more important that data be accurately labeled than it is for data to be listed as private. I don't know that this is the easiest possible approach for dealing with passed file descriptors in a MAC environment. It is going to make more developers happy than taking the approach that the UNIX community took during the 1990's secure system push. Passing descriptors was simply banned as bad practice then. The reality is that data that is shared, regardless of the mechanism, should be acknowledged and treated as such. To answer the inevitable SELinux question, it is necessary to point out that SELinux is a policy framework, and does not enforce a policy itself. The SELinux reference policy allows programs that expect to interact to interact in the way they have become accustom. This includes the use of file descriptor passing. The fine grained philosophy of SELinux policy development makes it difficult to identify what the SELinux community believes about the correct use of this mechanism. Thank you, and happy coding!
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
