Re: Regarding issue in defining file in file_contexts

2016-06-02 Thread William Roberts
On Thu, Jun 2, 2016 at 6:35 AM, Sameer Joshi  wrote:

> Thanks Stephen. It was my mistake that I did not do mkdir for
> eeprom_data_file correctly.
> After fixing this, it worked fine.
> I was using wrong user. cpnoui executes with user root and group system.
> After modifying user and group for eeprom_data_file during mkdir, issue was
> solved.
>

Running steady services (ie not-oneshot) with root will fail CTS. You
shouldn't really run services as user root, with very few exceptions. In
one case is things writing to kmsg like init.
You should pick a non root uid and use android_filesystem_config.h to
assign any needed capabilities. Examples exist for some nexus devices,
shamu as one.
If your on master, that has switched over to using config.fs ini files.

Additionally, perhaps using a non-core user is best, and you can assign a
uid in the oem reserved range (see android_filesystem_config.h) under
system/core. (just do find).
init services allow for number strings as user and group.



>
> Thanks again.
>
> On Thu, Jun 2, 2016 at 6:09 PM, Stephen Smalley  wrote:
>
>> On 06/02/2016 06:59 AM, Sameer Joshi wrote:
>> > Hi Stephen,
>> >
>> > I tried what you said:
>> >
>> > I have done following on trigger of post-fs-data in init..rc
>> file:
>> >
>> >mkdir /data/eeprom_data 777 system
>>
>> Why mode 777?  What else besides cpnoui needs access, and especially
>> what else needs write access?  Why are you assigning it the system UID?
>> Is that what cpnoui runs in? What group ownership should it have?
>>
>> > And I have defined following in file_contexts
>> >
>> > /data/eeprom_data(/.*)?  u:object_r:eeprom_data_file:s03
>>
>> Is the trailing "3" above a typo?
>> That would make the context invalid, but you should then be getting an
>> error at build time.
>>
>> >
>> > Did following in cpnoui.te:
>> >
>> >allpw cpnoui eeprom_data_file:dir rw_dir_perms;
>> > allow cpnoui eeprom_data_file:file create_file_perms;
>> >
>> > Also my program cpnoui is writing to a file under /data/eeprom_data/
>> >
>> > Still its giving the same error:
>> >
>> > type=1400 audit(1463139871.920:5): avc: denied { create } for pid=167
>> > comm="sh" name="eeprom_data_from_sysprops.tmp" scontext=u:r:cpnoui:s0
>> > tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
>> >
>> > Do I need to create the directory after specific trigger to make it
>> > readable by init as eeprom_data_file instead of system_data_file.
>>
>> No, if you have a matching entry with a valid context in /file_contexts
>> on the device, and if init is creating the directory (i.e. if the
>> directory does not already exist), then the directory should be created
>> with the context specified by the matching entry.  Further, even if the
>> directory already existed, if /file_contexts has changed since the last
>> boot (e.g. OTA), then the restorecon_recursive /data should relabel it
>> accordingly.
>>
>> Things to check:
>> 1. What is the current label of /data/eeprom_data?
>> ls -Z /data/eeprom_data
>>
>> 2. Does the file_contexts on the device include the entry you added?
>> adb shell grep /data/eeprom_data /file_contexts
>>
>> 3. What does restorecon think the label of /data/eeprom_data should be?
>> adb shell restorecon -nv /data/eeprom_data
>>
>
>
> ___
> 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.
>



-- 
Respectfully,

William C Roberts
___
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.

Re: Regarding issue in defining file in file_contexts

2016-06-02 Thread Stephen Smalley
On 06/02/2016 06:59 AM, Sameer Joshi wrote:
> Hi Stephen,
> 
> I tried what you said:
> 
> I have done following on trigger of post-fs-data in init..rc file:
> 
>mkdir /data/eeprom_data 777 system

Why mode 777?  What else besides cpnoui needs access, and especially
what else needs write access?  Why are you assigning it the system UID?
Is that what cpnoui runs in? What group ownership should it have?

> And I have defined following in file_contexts
> 
> /data/eeprom_data(/.*)?  u:object_r:eeprom_data_file:s03

Is the trailing "3" above a typo?
That would make the context invalid, but you should then be getting an
error at build time.

> 
> Did following in cpnoui.te:
> 
>allpw cpnoui eeprom_data_file:dir rw_dir_perms;
> allow cpnoui eeprom_data_file:file create_file_perms;
> 
> Also my program cpnoui is writing to a file under /data/eeprom_data/
> 
> Still its giving the same error: 
> 
> type=1400 audit(1463139871.920:5): avc: denied { create } for pid=167
> comm="sh" name="eeprom_data_from_sysprops.tmp" scontext=u:r:cpnoui:s0
> tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
> 
> Do I need to create the directory after specific trigger to make it
> readable by init as eeprom_data_file instead of system_data_file.

No, if you have a matching entry with a valid context in /file_contexts
on the device, and if init is creating the directory (i.e. if the
directory does not already exist), then the directory should be created
with the context specified by the matching entry.  Further, even if the
directory already existed, if /file_contexts has changed since the last
boot (e.g. OTA), then the restorecon_recursive /data should relabel it
accordingly.

Things to check:
1. What is the current label of /data/eeprom_data?
ls -Z /data/eeprom_data

2. Does the file_contexts on the device include the entry you added?
adb shell grep /data/eeprom_data /file_contexts

3. What does restorecon think the label of /data/eeprom_data should be?
adb shell restorecon -nv /data/eeprom_data
___
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.


Re: Regarding issue in defining file in file_contexts

2016-05-13 Thread Stephen Smalley
On 05/13/2016 07:52 AM, Sameer Joshi wrote:
> Hi,
> 
> I have defined following file context in file_contexts:
> 
> /data/eeprom_data_from_sysprops\.tmp  u:object_r:eeprom_data_file:s0 
> 
> and following in file.te: 
> 
> type eeprom_data_file, file_type, data_file_type;
> 
> Also I have added following in cpnoui.te ( a new domain defined for an
> executable) :
> 
> 
> allow cpnoui eeprom_data_file:file create;
> 
> Still I get following error:
> 
> 
> type=1400 audit(1463139871.920:5): avc: denied { create } for pid=167
> comm="sh" name="eeprom_data_from_sysprops.tmp" scontext=u:r:cpnoui:s0
> tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
> 
> This indicates that eeprom_data_from_sysprops.tmp file is still not
> being as from the domain eeprom_data_file,
> 
> Please let me know what could be the problem.

file_contexts is a userspace configuration used at build time to label
the initial filesystem images and consulted by specific programs (e.g.
init, ueventd, etc) at runtime to determine labels for directories and
files they create.  It is not used by the kernel and won't affect
runtime file creation.   For the latter, you would need a
type_transition rule in your policy, ala
type_transition cpnoui system_data_file:file eeprom_data_file;

However, this is NOT the recommended way to solve this problem.

It would be better to define a separate subdirectory of /data for this
file (e.g. /data/eeprom_data), create this directory from your
init..rc file, assign the directory and all files within it a
label in file_contexts (e.g. /data/eeprom_data(/.*)?
u:object_r:eeprom_data_file:s0), and then create your file in this
directory (i.e. /data/eeprom_data/eeprom_data_from_sysprops.tmp, or
whatever name you choose to use).  This approach has the following
advantages:

1) Your process (cpnoui) will not need { write add_name } permissions to
system_data_file:dir (and hence won't be allowed to write to other /data
directories it has no business modifying).

2) init already uses file_contexts to determine the label of directories
it creates, so it will create the directory in the right label
automatically.

3) When your process creates files in that directory, they will
automatically inherit the type of the parent directory and you won't
need to explicitly label them.

Regardless, when allowing permissions, please using the macros in
global_macros.  Instead of merely allowing create (and then running into
denials when your process tries to perform any other operation), use
create_file_perms, ala:
allpw cpnoui eeprom_data_file:dir rw_dir_perms;
allow cpnoui eeprom_data_file:file create_file_perms;

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


Regarding issue in defining file in file_contexts

2016-05-13 Thread Sameer Joshi
Hi,

I have defined following file context in file_contexts:

/data/eeprom_data_from_sysprops\.tmp  u:object_r:eeprom_data_file:s0

and following in file.te:

type eeprom_data_file, file_type, data_file_type;

Also I have added following in cpnoui.te ( a new domain defined for an
executable) :


allow cpnoui eeprom_data_file:file create;

Still I get following error:


type=1400 audit(1463139871.920:5): avc: denied { create } for pid=167
comm="sh" name="eeprom_data_from_sysprops.tmp" scontext=u:r:cpnoui:s0
tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0

This indicates that eeprom_data_from_sysprops.tmp file is still not being
as from the domain eeprom_data_file,

Please let me know what could be the problem.

Regards,

Sameer Joshi
___
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.