Seeing new denial on AOSP 5.1.1 w.r.t shell request read access on lnk_file .

[Ravi Kumar <nxp.ravi@xxxxxxxxx>]

Hi Team  ,

I am seeing some new denial when running the CTS test cases  which is as follows

avc: denied { read } for pid=6013 comm="sh" name="app_process" dev="mmcblk0p24" ino=410 scontext=u:r:shell:s0 tcontext=u:object_r:zygote_exec:s0 tclass=lnk_file permissive=0

where app_process is link created to point app_process32/app_process64 binary when doing a  ls -Z  i see the context of this is as expected and  tcontext on the denial  is also as expected (as below ).

root# ls -Z |grep app
lrwxr-xr-x root     shell             u:object_r:zygote_exec:s0 app_process -> app_process64
-rwxr-xr-x root     shell             u:object_r:zygote_exec:s0 app_process32
-rwxr-xr-x root     shell             u:object_r:zygote_exec:s0 app_process64


I can see that there are NO changes in sepolicy for shell domain / Zygote domain.
Only change is the kernel migration from 3.10.48  to 3.10.73(policy version 28)  and i see there are  couple of changes done in security . Looking at the changes  I don't see any suspicious changes which could impact the shell domain nature. Adding the rule is surely  going to addressing the issue but wonder why at first place it is needed  from security point of view i don't think adding just read should create a problem as the  lnk_files is as good as common_file and to as  write/execute are not given should not be at risk.  Please let me know if we have any changes which could cause this or any comment on this will be of great help .

Thanks ,

Ravi

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.