On 11/29/2012 07:41 AM, Peck, Michael A wrote:
Thanks. Should I submit that to Google, or do you like to bundle up minor policy changes and submit them together? Does that over-privilege the mediaserver? In this case it doesn't really need full write access to all app data files - the application is opening a specific data file and passing the file descriptor to the mediaserver. Read access for playing back media looks similar. Is there a better way to handle that - such as giving mediaserver read and write but not open?
You may need to wait on other pending changes that modify mediaserver.te to get merged. There are a couple that William Roberts just uploaded. And likely you should perform more extensive testing of the mediaserver functionality and collect up all of the relevant changes into one change.
You could try testing the mediaserver with just { read write } permissions by removing the current allow rule that grants r_file_perms (which includes open) and replacing it with one that only allows { read write}. But you'd need to do code analysis and/or full testing of mediaserver functionality to confirm that it never legitimately requires open permission to the app data files. We have seen a mix of passing files by open fd and passing them by pathname followed by an open in Android.
Originally SELinux did not distinguish open at all; as a MAC mechanism, it was primarily concerned with whether a process had read or write access to a file at all, not how the access was obtained. The same read/write permissions were checked upon open(), upon fd inheritance across a context-changing execve(), and upon fd transfer across a local socket, and those same read/write permissions were revalidated on read()/write() to account for any policy change or file relabeling.
Circa Linux 2.6.26, Red Hat introduced a separate open permission that is only applied upon open() to distinguish the ability to open the file. However, as it is just a single open permission (rather than open_read and open_write), if you allow it, you are allowing open with whatever other read/write permissions are allowed in the policy. So by adding "allow mediaserver app_data_file:file { write };" to a policy that already contains "allow mediaserver app_data_file:file r_file_perms;", you are effectively allowing opening with write access as well. So you have to replace the current rule if you want to prevent opening the file directly.
Another approach would be to have the app set the label explicitly on the file to indicate that it is intended to be shared with the mediaserver. But at that point you are getting into the realm of a security-aware application.
-- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
