On 10/17/2016 11:19 PM, peng fei wrote:
> I want to achieve the result that just allow jd process to open and
> read /data/audit/log/audit.log. 
> For this target, I add some rules in policy file.
> And after that, I want to verify my policy. So, I create a test.c to
> read  /data/audit/log/audit.log. Using gcc to build the test.c to
> executable test.The file test.c and test is in /home/pengfei.
> -----------------------------------------------------------------
> My modify policy are as follows:
> --
> First,
> add new type in file.te 
> #/data/audit/log/audit.log
> type sec_file, file_type, data_file_type;
> #/home/test
> type jd_exec, file_type;
> --
> add the contexts in the file_contexts
> /data/audit/log/audit.log       u:object_r:sec_file:s0
> /home/pengfei/test             u:object_r:jd_exec:s0 
> --
> add rule in jd.te
> allow jd sec_file:file {read, open };
> allow jd  jd_exec:file rx_file_perms;
> -------------------------------------------------
> How can I verify my policy? Can I create a executable file to imitate
> jd. How to assign the  conte
> Please help me. Thanks advance.

Stock Android handles auditing via logd, and those logs can be read via
logcat, so I'm not sure what your /data/audit/log/audit.log is.

/home doesn't normally exist on Android AFAIK. Executables should
generally live in /system/bin.  Plenty of /system/bin examples in the
base AOSP file_contexts file.  If you include the jd binary in your
system image and specify a context for /system/bin/jd in your
file_contexts, it will be labeled at build time; you won't need to do
anything extra to label it.

If jd is a daemon started by init, then you want to include:
in your jd.te policy to set up the domain transition.

The easiest way is to use one of the existing domains from AOSP as an

Use policy macros where possible to make your policy less brittle, e.g.
allow jd sec_file:file r_file_perms;

On a userdebug or eng build, you can su from an adb shell and then use
runcon to run the program in a particular context for testing purposes,
but this may not match the behavior you will see when running it as a


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