On 10/18/2016 12:26 PM, Stephen Smalley wrote:
> 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.

Yes, looks like you would need to add a SELinux.restorecon() call right
after the rulesDir.mkdirs() call in IntentFirewall().

Seandroid-list mailing list
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 

Reply via email to