Something went wrong on our end
-
Stephen Smalley authored
Various third party apps come with their own binaries that they write out to their sandbox directories and then execute, e.g.: audit(1386527439.462:190): avc: denied { execute_no_trans } for pid=1550 comm="Thread-79" path="/data/data/com.cisco.anyconnect.vpn.android.avf/app_bin/busybox" dev="mmcblk0p23" ino=602891 scontext=u:r:untrusted_app:s0:c39,c256 tcontext=u:object_r:app_data_file:s0:c39,c256 tclass=file While this is not ideal from a security POV, it seems necessary to support for compatibility with Android today. Split out the execute-related permissions to a separate allow rule as it only makes sense for regular files (class file) not other kinds of files (e.g. fifos, sockets, symlinks), and use the rx_file_perms macro. Move the rule to untrusted_app only so that we do not permit system apps to execute files written by untrusted apps. Change-Id: Ic9bfe80e9b14f2c0be14295c70f23f09691ae66c Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
Stephen Smalley authoredVarious third party apps come with their own binaries that they write out to their sandbox directories and then execute, e.g.: audit(1386527439.462:190): avc: denied { execute_no_trans } for pid=1550 comm="Thread-79" path="/data/data/com.cisco.anyconnect.vpn.android.avf/app_bin/busybox" dev="mmcblk0p23" ino=602891 scontext=u:r:untrusted_app:s0:c39,c256 tcontext=u:object_r:app_data_file:s0:c39,c256 tclass=file While this is not ideal from a security POV, it seems necessary to support for compatibility with Android today. Split out the execute-related permissions to a separate allow rule as it only makes sense for regular files (class file) not other kinds of files (e.g. fifos, sockets, symlinks), and use the rx_file_perms macro. Move the rule to untrusted_app only so that we do not permit system apps to execute files written by untrusted apps. Change-Id: Ic9bfe80e9b14f2c0be14295c70f23f09691ae66c Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>