On 10/18/2016 10:23 AM, William Roberts wrote:
> On Oct 18, 2016 9:34 AM, "Sava Mikalački" <mikalac...@gmail.com
> <mailto:mikalac...@gmail.com>> wrote:
>> I'm trying to extend aosp file_contexts by adding a new entry for
> /data/system/ifw. I've created a file_contexts under my vendor directory
> structure but if I try to use the new label, build crashes with unknown
> type. I'm
> You need to declare the type with the type keyword:
> type system_data_ifw, file_type;
> trying to enable a platform_app to write to data/system/ifw and here is
> what I have so far:
>> file_contexts:
>> /data/system/ifw(/.*)?                       u:object_r:system_data_ifw:s0
>> platform_app.te:
>> allow platform_app system_data_ifw:file create_file_perms;
> Platform applications shouldn't be creating stuff around the system,
> they should stick to their sandbox. I cant recall offhand, but a never
> allow I wrote might assert itself on that allow rule.

Probably not since it is a new type he just defined.  However, it occurs
to me that DAC will be a problem for this use case, since platform apps
can be assigned arbitrary UIDs and thus won't be able to pass the DAC
checks on writing to /data/system/ifw unless you set up a group, map a
permission to that group, assign that group to /data/system/ifw, and
make it group-writable.  Simpler if you use a system_app or some other
fixed UID app instead, although that carries its own set of issues.

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