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
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.
