Skip to content
Snippets Groups Projects
Select Git revision
  • 6d10ca8fb6b2938b4b45a7512e483420d892842a
  • master default protected
  • android-7.1.2_r28_klist
  • 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
41 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>
    untrusted_app.te 1.86 KiB
    ###
    ### Untrusted apps.
    ###
    ### This file defines the rules for untrusted apps. An "untrusted
    ### app" is an APP with UID between APP_AID (10000)
    ### and AID_ISOLATED_START (99000).
    ###
    ### untrusted_app includes all the appdomain rules, plus the
    ### additional following rules:
    ###
    
    type untrusted_app, domain;
    permissive untrusted_app;
    app_domain(untrusted_app)
    net_domain(untrusted_app)
    bluetooth_domain(untrusted_app)
    
    # Some apps ship with shared libraries and binaries that they write out
    # to their sandbox directory and then execute.
    allow untrusted_app app_data_file:file rx_file_perms;
    
    allow untrusted_app tun_device:chr_file rw_file_perms;
    
    # Internal SDCard rw access.
    allow untrusted_app sdcard_internal:dir create_dir_perms;
    allow untrusted_app sdcard_internal:file create_file_perms;
    
    # External SDCard rw access.
    allow untrusted_app sdcard_external:dir create_dir_perms;
    allow untrusted_app sdcard_external:file create_file_perms;
    
    # ASEC
    allow untrusted_app asec_apk_file:dir { getattr };
    allow untrusted_app asec_apk_file:file r_file_perms;
    
    # Create tcp/udp sockets
    allow untrusted_app node_type:{ tcp_socket udp_socket } node_bind;
    allow untrusted_app self:{ tcp_socket udp_socket } { create_socket_perms accept listen };
    # Bind to a particular hostname/address/interface (e.g., localhost) instead of
    # ANY. Normally, apps should not be listening on all interfaces.
    allow untrusted_app port:{ tcp_socket udp_socket } name_bind;
    
    # Allow the allocation and use of ptys
    # Used by: https://play.google.com/store/apps/details?id=jackpal.androidterm
    create_pty(untrusted_app)
    
    # Used by Finsky / Android "Verify Apps" functionality when
    # running "adb install foo.apk".
    # TODO: Long term, we don't want apps probing into shell data files.
    # Figure out a way to remove these rules.
    allow untrusted_app shell_data_file:file r_file_perms;
    allow untrusted_app shell_data_file:dir r_dir_perms;