On 12/11/2014 03:05 PM, Biswajit Paul wrote:
> Hi All,
>
>
>
> I have one use case on that requires us to dynamically change the
> display density depending on the resolution of the display connected.
>
>
>
> For example, when connecting a 720p display, if I need to change the
> display density from 320 to 213, this is achieved by the following command
>
>
>
> adb shell wm density 213
>
>
>
> or via the system command from the Surface Flinger process
>
>
>
> system(“wm density 213”);
>
>
>
> However, I am seeing denials when I try to execute this command from
> SurfaceFlinger:
>
>
>
> avc: denied { execute } for pid=22692 comm="surfaceflinger" name="sh"
> dev="mmcblk0p15" ino=256 scontext=u:r:surfaceflinger:s0
> tcontext=u:object_r:shell_exec:s0 tclass=file
>
> avc: denied { read open } for pid=22692 comm="surfaceflinger"
> path="/system/bin/sh" dev="mmcblk0p15" ino=256
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:shell_exec:s0 tclass=file
>
> avc: denied { execute_no_trans } for pid=22692 comm="surfaceflinger"
> path="/system/bin/sh" dev="mmcblk0p15" ino=256
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:shell_exec:s0 tclass=file
>
> avc: denied { execute_no_trans } for pid=22692 comm="sh"
> path="/system/bin/wm" dev="mmcblk0p15" ino=290
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:system_file:s0
> tclass=file
>
> avc: denied { getattr } for pid=22692 comm="sh"
> path="/system/bin/app_process32" dev="mmcblk0p15" ino=95
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:zygote_exec:s0
> tclass=file
>
> avc: denied { execute } for pid=22692 comm="sh" name="app_process32"
> dev="mmcblk0p15" ino=95 scontext=u:r:surfaceflinger:s0
> tcontext=u:object_r:zygote_exec:s0 tclass=file
>
> avc: denied { read open } for pid=22692 comm="sh"
> path="/system/bin/app_process32" dev="mmcblk0p15" ino=95
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:zygote_exec:s0
> tclass=file
>
> avc: denied { execute_no_trans } for pid=22692 comm="sh"
> path="/system/bin/app_process32" dev="mmcblk0p15" ino=95
> scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:zygote_exec:s0
> tclass=file
>
> avc: denied { execute } for pid=22692 comm="app_process"
> path="/data/dalvik-cache/arm/system@[email protected]
> <mailto:/data/dalvik-cache/arm/system@[email protected]>"
> dev="mmcblk0p25" ino=40964 scontext=u:r:surfaceflinger:s0
> tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
>
>
>
>
>
> rules it translates to:
>
>
>
> #============= surfaceflinger ==============
>
> allow surfaceflinger dalvikcache_data_file:file execute;
>
> allow surfaceflinger shell_exec:file { read execute open execute_no_trans };
>
> allow surfaceflinger system_file:file execute_no_trans;
>
> allow surfaceflinger zygote_exec:file { read getattr open execute
> execute_no_trans };
>
>
>
> file execution is never allowed by core sepolicy and allowed only for
> couple of domains as mentioned in external/sepolicy/domain.te. Can
> someone suggest alternatives on how to execute system command on
> dalvikcache_data_file from domains other than listed in core sepolicy
> without violating the core policy.
Options are:
1. Have surfaceflinger directly execute whatever underlying code
implements this action rather than executing external helpers, or
2. Define a new domain for external helpers executed by surfaceflinger,
and transition to this new domain automatically when surfaceflinger
executes shell_exec or system_file. Make this domain have only those
permissions required for the helper(s).
The goal is to ensure that you can't execute arbitrary code with the
surfaceflinger's permissions.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
