Skip to content
Snippets Groups Projects
Select Git revision
  • android-7.1.2_r28_klist
  • master default protected
  • pie-cts-release
  • pie-vts-release
  • pie-cts-dev
  • oreo-mr1-iot-release
  • sdk-release
  • oreo-m6-s4-release
  • oreo-m4-s12-release
  • pie-release
  • pie-r2-release
  • pie-r2-s1-release
  • oreo-vts-release
  • oreo-cts-release
  • oreo-dev
  • oreo-mr1-dev
  • pie-gsi
  • pie-platform-release
  • pie-dev
  • oreo-cts-dev
  • android-o-mr1-iot-release-1.0.4
  • android-9.0.0_r8
  • android-9.0.0_r7
  • android-9.0.0_r6
  • android-9.0.0_r5
  • android-8.1.0_r46
  • android-8.1.0_r45
  • android-n-iot-release-smart-display-r2
  • android-vts-8.1_r5
  • android-cts-8.1_r8
  • android-cts-8.0_r12
  • android-cts-7.1_r20
  • android-cts-7.0_r24
  • android-o-mr1-iot-release-1.0.3
  • android-cts-9.0_r1
  • android-8.1.0_r43
  • android-8.1.0_r42
  • android-n-iot-release-smart-display
  • android-p-preview-5
  • android-9.0.0_r3
40 results

untrusted_app.te

Blame
    • Stephen Smalley's avatar
      65317124
      Allow untrusted apps to execute binaries from their sandbox directories. · 65317124
      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: default avatarStephen Smalley <sds@tycho.nsa.gov>
      65317124
      History
      Allow untrusted apps to execute binaries from their sandbox directories.
      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: default avatarStephen Smalley <sds@tycho.nsa.gov>