On 07/12/2016 11:57 AM, Roman Mazur wrote:
> I'm working on a custom build based on Android 6.0.1 for Nexus 7. This
> custom build adds a special daemon that is started from init.rc and
> exposes some API to applications. Particularly, one of available methods
> creates a new file at /data/daemon_dir and returns a file descriptor
> making it possible to write to this file from an app.
>
> The daemon has its own SELinux context (here it's named custom_daemon).
> And /data/daemon_dir has custom_daemon_file context. There are sepolicy
> rules that grant file creation to the daemon and file writes to
> untrusted_app.
>
> The configuration described above worked on Android 5. But after merging
> with Android 6, I'm getting the following denial:
>
> 07-11 21:57:46.735 13389-13389/? W/Binder_2: type=1400 audit(0.0:945):
> avc: denied { write } for path="/data/daemon_dir/some_file"
> dev="mmcblk0p30" ino=496817 scontext=u:r:untrusted_app:s0:c512,c768
> tcontext=u:object_r:custom_daemon_file:s0 tclass=file permissive=0
>
>
> Here are the rules that should allow the operation:
>
> allow untrusted_app custom_daemon_file:file rw_file_perms;
> allow untrusted_app custom_daemon_file:dir r_dir_perms;
(cc seandroid-list)
Assuming that you only want to allow apps to read and write files passed
to them explicitly by your daemon and not to directly open files in this
directory, you should only have:
allow untrusted_app custom_daemon_file:file { read write getattr };
In particular, you would not need to allow open permission to file nor
any permissions to the directory in this usage model, and not allowing
those permissions would be more secure as it would prevent apps from
directly accessing any of those files without going through your daemon.
> allow custom_daemon custom_daemon_file:dir create_dir_perms;
> allow custom_daemon custom_daemon_file:file create_file_perms;
>
>
> An interesting thing in this denial report is that scontext is
> untrusted_app. But the denial is logged for the daemon process (13389 is
> one of its thread IDs and Binder_2 is a name of the binder thread that
> handles the API call).
>
> I believe this mismatch is what is causing the denial but cannot
> understand why this happens and how this can be fixed.
No, the denial is caused by the fact that the app is running with
categories (c512,c768) and the file is not labeled with the same
categories. You can allow this by adding the mlstrustedobject attribute
to your type:
type custom_daemon_file, file_type, data_file_type, mlstrustedobject;
In 6.0, apps and their data files are assigned an automatically
generated category set (c512,c768 above) derived from their user ID in
order to isolate the processes and files of different users from each
other. This prevents cross-user or cross-profile access to /proc/pid
files and app data files, even if world-readable or -writable (sharing
is still possible by having the owning app open the file itself and pass
the file descriptor over binder or local socket IPC to another app, but
direct open is prohibited). This separation is currently applied to
untrusted apps and platform apps as a result of specifying
levelFrom=user in the seapp_contexts configuration.
With regard to the potentially misleading audit message, it is due to
the fact that this check occurs when your daemon tries to pass the open
file descriptor to the app, so it occurs while the daemon is the current
process. Before transferring the descriptor into the app's descriptor
table, SELinux checks whether the app is allowed to use it. So the
check is between the app's context and the file, but happens while the
daemon is still the current process.
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
