On 10/18/2016 01:01 PM, Sava Mikalački wrote:
> And if I label it in init.rc (I have my custom one), would I need to
> call restorecon() anyways?

No, if you add a mkdir /data/system/ifw to your init.rc post-fs-data
section, then init will create it with whatever label you specify in
file_contexts, and then it should be fine without needing to modify
IntentFirewall code (assuming nothing ever deletes the directory once
created).

Conceivably you could also achieve the same effect through a name-based
type transition rule in policy, but probably not worth it:
type_transition system_server system_data_file:dir system_data_ifw "ifw";

> 
> 
> On Oct 18, 2016 18:41, "Stephen Smalley" <s...@tycho.nsa.gov
> <mailto:s...@tycho.nsa.gov>> wrote:
> 
>     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.

Reply via email to