On Oct 18, 2016 9:02 AM, "Stephen Smalley" <s...@tycho.nsa.gov> wrote:
>
> 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 you're on OEM it's encouraged to place your executables in the vendor
partition, labelling occurs the same way, at build.
>
> If jd is a daemon started by init, then you want to include:
> init_daemon_domain(jd)
> 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
> example.
>
> 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
> daemon.
>
> Resources:
> https://source.android.com/security/selinux/index.html
>
https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf
>
>
>
>
> _______________________________________________
> 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.
_______________________________________________
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.
