On 10/18/2016 11:43 AM, Sava Mikalački wrote:
> Yup, exactly as Stephen said. When I set my app to share the system uid,
> I do get the following denial:
> type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
> ino=678613 scontext=u:r:system_app:s0
> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
>
> Here is the output of the commands Stephen pointed out:
> $ ls -lZd /data/system/ifw
> drwx------ 2 system system u:object_r:system_data_file:s0 4096
> 1971-01-02 12:23 /data/system/ifw
>
> $ ps -eZ | grep com.ariel.guardian
> system 4017 503 1588756 68980 SyS_epoll_ 768b37aa74 S
> com.ariel.guardian
>
> So, if I create a new file type label and assign allow rule to the
> system_app for this file type, would that (at least in theory) work?
You'll need to allow access to the directory as well (your earlier
policy only had an allow rule for class file; you'll need rw_dir_perms
to the :dir as well).
The other issue is getting /data/system/ifw labeled correctly. Doesn't
look like it is created by the init.rc file, so it won't automatically
be labeled based on file_contexts (init does that for anything it
creates). Probably created by the IntentFirewall code, and may need you
to call SELinux.restorecon() on it after creating it. You'll see some
examples in other code, e.g.
frameworks/base/services/core/java/com/android/server/pm/PackageInstallerService.java
or wallpaper/WallpaperManagerService.java.
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
