Skip to content
Snippets Groups Projects
  1. Feb 10, 2015
  2. Oct 29, 2014
    • Stephen Smalley's avatar
      Switch kernel and init to permissive_or_unconfined(). · a523aaca
      Stephen Smalley authored
      
      Switch the kernel and init domains from unconfined_domain()
      to permissive_or_unconfined() so that we can start collecting
      and addressing denials in -userdebug/-eng builds.
      
      Also begin to address denials for kernel and init seen after
      making this switch.
      
      I intentionally did not allow the following denials on hammerhead:
      avc:  denied  { create } for  pid=1 comm="init" name="memory.move_charge_at_immigrate" scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
      avc:  denied  { open } for  pid=1 comm="init" name="memory.move_charge_at_immigrate" dev="tmpfs" ino=6550 scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
      
      These occur when init.rc does:
      write /sys/fs/cgroup/memory/memory.move_charge_at_immigrate 1
      because the prior command to mount the cgroup failed:
      mount cgroup none /sys/fs/cgroup/memory memory
      
      I think this is because that cgroup is not enabled in the
      kernel configuration.  If the cgroup mount succeeded,
      then this would have been a write to a cgroup:file and
      would have been allowed already.
      
      Change-Id: I9d7e31bef6ea91435716aa4312c721fbeaeb69c0
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      a523aaca
  3. Sep 09, 2014
    • Nick Kralevich's avatar
      Allow kernel thread to read app data files · b0a99513
      Nick Kralevich authored
      When vold mounts an OBB on behalf of another application, the kernel
      spins up the "loop0" thread to perform the mount operation. Grant
      the kernel thread the ability to read app data files, so the mount
      operation can succeed.
      
      Steps to reproduce:
      
        1) Run: runtest --path cts/tests/tests/os/src/android/os/storage/cts/StorageManagerTest.java
      
      Expected:
      
        1) All tests pass
      
      Actual:
      
        Test failure, with the following error message:
      
        loop0   : type=1400 audit(0.0:46): avc: denied { read } for path="/data/data/com.android.cts.stub/files/test1.obb" dev="mmcblk0p16" ino=115465 scontext=u:r:kernel:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
        Vold    : Image mount failed (I/O error)
        MountService: Couldn't mount OBB file: -1
        StorageManager: Received message.  path=/data/data/com.android.cts.stub/files/test1.obb, state=21
        TestRunner: failed: testMountAndUnmountObbNormal(android.os.storage.cts.StorageManagerTest)
        TestRunner: ----- begin exception -----
        TestRunner: junit.framework.AssertionFailedError: OBB should be mounted
        TestRunner:    at junit.framework.Assert.fail(Assert.java:50)
        TestRunner:    at junit.framework.Assert.assertTrue(Assert.java:20)
        TestRunner:    at android.os.storage.cts.StorageManagerTest.mountObb(StorageManagerTest.java:235)
      
      Bug: 17428116
      Change-Id: Id1a39a809b6c3942ff7e08884b40e3e4eec73b6a
      b0a99513
  4. Aug 27, 2014
    • Nick Kralevich's avatar
      support kernel writes to external SDcards · 28b26bcf
      Nick Kralevich authored
      The kernel, when it creates a loop block device, starts a new
      kernel thread "loop0" (drivers/block/loop.c). This kernel thread,
      which performs writes on behalf of other processes, needs read/write
      privileges to the sdcard. Allow it.
      
      Steps to reproduce:
      0) Get device with external, removable sdcard
      1) Run: "adb install -s foo.apk"
      
      Expected:
      
        APK installs successfully.
      
      Actual:
      
        APK fails to install. Error message:
      
          Vold  E  Failed to write superblock (I/O error)
          loop0  W  type=1400 audit(0.0:3123): avc: denied { read } for path="/mnt/secure/asec/smdl1645334795.tmp.asec" dev="mmcblk1p1" ino=528 scontext=u:r:kernel:s0 tcontext=u:object_r:vfat:s0 tclass=file permissive=0
          PackageHelper  E  Failed to create secure container smdl1645334795.tmp
          DefContainer  E  Failed to create container smdl1645334795.tmp
      
      Bug: 17158723
      
      (cherry picked from commit 4c6b1350)
      
      Change-Id: Iea727ac7958fc31d85a037ac79badbe9c85693bd
      28b26bcf
    • Nick Kralevich's avatar
      support kernel writes to external SDcards · 4c6b1350
      Nick Kralevich authored
      The kernel, when it creates a loop block device, starts a new
      kernel thread "loop0" (drivers/block/loop.c). This kernel thread,
      which performs writes on behalf of other processes, needs read/write
      privileges to the sdcard. Allow it.
      
      Steps to reproduce:
      0) Get device with external, removable sdcard
      1) Run: "adb install -s foo.apk"
      
      Expected:
      
        APK installs successfully.
      
      Actual:
      
        APK fails to install. Error message:
      
          Vold  E  Failed to write superblock (I/O error)
          loop0  W  type=1400 audit(0.0:3123): avc: denied { read } for path="/mnt/secure/asec/smdl1645334795.tmp.asec" dev="mmcblk1p1" ino=528 scontext=u:r:kernel:s0 tcontext=u:object_r:vfat:s0 tclass=file permissive=0
          PackageHelper  E  Failed to create secure container smdl1645334795.tmp
          DefContainer  E  Failed to create container smdl1645334795.tmp
      
      Bug: 17158723
      Change-Id: I4aa86e372cc55348f6b8becfa17bd4da583925d4
      4c6b1350
  5. Jul 15, 2014
  6. Jul 08, 2014
    • Stephen Smalley's avatar
      Rename sdcard_internal/external types. · 374b2a19
      Stephen Smalley authored
      
      Rename sdcard_internal/external types to fuse and vfat
      respectively to make it clear that they are assigned to any
      fuse or vfat filesystem by default (absent a context= mount option)
      and do not necessarily represent the SDcard.
      
      The sdcard_type attribute is still assigned to both types and
      can still be used in allow rules to permit access to either the
      internal or external SDcard.
      
      Define type aliases for the old names to preserve compatibility
      on policy reload and for device-specific policies that may not yet
      be updated.
      
      Change-Id: I8d91a8c4c1342b94e4f1bb62ca7ffd2ca4b06ba1
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      374b2a19
  7. Jun 24, 2014
  8. Jun 19, 2014
    • Stephen Smalley's avatar
      Remove execute_no_trans from unconfineddomain. · f3c3a1aa
      Stephen Smalley authored
      
      execute_no_trans controls whether a domain can execve a program
      without switching to another domain.  Exclude this permission from
      unconfineddomain, add it back to init, init_shell, and recovery for
      files in / and /system, and to kernel for files in / (to permit
      execution of init prior to setcon).  Prohibit it otherwise for the
      kernel domain via neverallow.  This ensures that if a kernel task
      attempts to execute a kernel usermodehelper for which no domain transition
      is defined, the exec will fail.
      
      Change-Id: Ie7b2349923672dd4f5faf7c068a6e5994fd0e4e3
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      f3c3a1aa
  9. Jun 18, 2014
    • Stephen Smalley's avatar
      Prevent adding transitions to kernel or init domains. · bac4ccce
      Stephen Smalley authored
      
      Add neverallow rules to prohibit adding any transitions into
      the kernel or init domains.  Rewrite the domain self:process
      rule to use a positive permission list and omit the transition
      and dyntransition permissions from this list as well as other
      permissions only checked when changing contexts.  This should be
      a no-op since these permissions are only checked when
      changing contexts but avoids needing to exclude kernel or init
      from the neverallow rules.
      
      Change-Id: Id114b1085cec4b51684c7bd86bd2eaad8df3d6f8
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      bac4ccce
    • Stephen Smalley's avatar
      Allow mounting of usbfs. · 718bf84b
      Stephen Smalley authored
      
      Addresses denials such as:
      avc:  denied  { mount } for  pid=5 comm="kworker/u:0" name="/" dev=usbfs ino=3234 scontext=u:r:kernel:s0 tcontext=u:object_r:usbfs:s0 tclass=filesystem
      
      Change-Id: I1db52193e6a2548c37a7809ef44cf7fd3357326d
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      718bf84b
  10. May 30, 2014
  11. May 29, 2014
    • Stephen Smalley's avatar
      Clean up kernel, init, and recovery domains. · eb1bbf26
      Stephen Smalley authored
      
      Narrow the relabelto rules to a more specific type set
      for each domain.
      
      Drop mount permissions from the kernel domain since mounting
      occurs after switching to the init domain.  This was likely
      a residual of when all processes were left in the kernel domain
      on a recovery boot due to the missing setcon statement in the
      recovery init.rc.
      
      Be consistent with unlabeled filesystems (i.e. filesystems
      without any matching fs_use or genfs_contexts entry) so
      that we can also unmount them.
      
      Add comments to note the reason for various rules.
      
      Change-Id: I269a1744ed7bf8c6be899494c5dc97847e5a994d
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      eb1bbf26
    • Nick Kralevich's avatar
      Remove /system write from unconfined · 03ce5120
      Nick Kralevich authored
      Don't allow writes to /system from unconfined domains.
      /system is always mounted read-only, and no process should
      ever need to write there.
      
      Allow recovery to write to /system. This is needed to apply OTA
      images.
      
      Change-Id: I11aa8bd0c3b7f53ebe83806a0547ab8d5f25f3c9
      03ce5120
  12. May 23, 2014
    • Stephen Smalley's avatar
      Restrict requesting contexts other than policy-defined defaults. · 356f4be6
      Stephen Smalley authored
      
      Writing to the /proc/self/attr files (encapsulated by the libselinux
      set*con functions) enables a program to request a specific security
      context for various operations instead of the policy-defined defaults.
      The security context specified using these calls is checked by an
      operation-specific permission, e.g. dyntransition for setcon,
      transition for setexeccon, create for setfscreatecon or
      setsockcreatecon, but the ability to request a context at all
      is controlled by a process permission.  Omit these permissions from
      domain.te and only add them back where required so that only specific
      domains can even request a context other than the default defined by
      the policy.
      
      Change-Id: I6a2fb1279318625a80f3ea8e3f0932bdbe6df676
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      356f4be6
  13. May 14, 2014
  14. May 12, 2014
    • Nick Kralevich's avatar
      Revisit kernel setenforce · abae8a9b
      Nick Kralevich authored
      Kernel userspace helpers may be spawned running in the kernel
      SELinux domain. Those userspace helpers shouldn't be able to turn
      SELinux off.
      
      This change revisits the discussion in
      https://android-review.googlesource.com/#/c/71184/
      
      At the time, we were debating whether or not to have an allow rule,
      or a dontaudit rule. Both have the same effect, as at the time we
      switch to enforcing mode, the kernel is in permissive and the operation
      will be allowed.
      
      Change-Id: If335a5cf619125806c700780fcf91f8602083824
      abae8a9b
  15. May 09, 2014
  16. Feb 12, 2014
  17. Feb 11, 2014
  18. Jan 27, 2014
    • Nick Kralevich's avatar
      Remove transition / dyntransition from unconfined · fed8a2a4
      Nick Kralevich authored
      Require all domain transitions or dyntransitions to be
      explicitly specified in SELinux policy.
      
      healthd: Remove healthd_exec / init_daemon_domain().
      Healthd lives on the rootfs and has no unique file type.
      It should be treated consistent with other similar domains.
      
      Change-Id: Ief3c1167379cfb5383073fa33c9a95710a883b29
      fed8a2a4
  19. Jan 08, 2014
  20. Dec 06, 2013
    • Stephen Smalley's avatar
      Allow kernel domain, not init domain, to set SELinux enforcing mode. · fea6e66f
      Stephen Smalley authored
      As per the discussion in:
      https://android-review.googlesource.com/#/c/71184/
      
      
      
      init sets the enforcing mode in its code prior to switching to
      the init domain via a setcon command in the init.rc file.  Hence,
      the setenforce permission is checked while still running in the
      kernel domain.  Further, as init has no reason to ever set the
      enforcing mode again, we do not need to allow setenforce to the
      init domain and this prevents reverting to permissive
      mode via an errant write by init later.  We could technically
      dontaudit the kernel setenforce access instead since the first
      call to setenforce happens while still permissive (and thus we
      never need to allow it in policy) but we allow it to more accurately
      represent what is possible.
      
      Change-Id: I70b5e6d8c99e0566145b9c8df863cc8a34019284
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      fea6e66f
    • Nick Kralevich's avatar
      Revert "Allow kernel domain, not init domain, to set SELinux enforcing mode." · 9e8b8d9f
      Nick Kralevich authored
      The build is broken. Reverting temporarily to fix breakage.
      
      libsepol.check_assertion_helper: neverallow on line 4758 violated by allow init kernel:security { setenforce };
      Error while expanding policy
      make: *** [out/target/product/mako/obj/ETC/sepolicy_intermediates/sepolicy] Error 1
      make: *** Waiting for unfinished jobs....
      
      
      This reverts commit bf12e225.
      
      Change-Id: I78a05756d8ce3c7d06e1d9d27e6135f4b352bb85
      9e8b8d9f
    • Stephen Smalley's avatar
      Allow kernel domain, not init domain, to set SELinux enforcing mode. · bf12e225
      Stephen Smalley authored
      As per the discussion in:
      https://android-review.googlesource.com/#/c/71184/
      
      
      
      init sets the enforcing mode in its code prior to switching to
      the init domain via a setcon command in the init.rc file.  Hence,
      the setenforce permission is checked while still running in the
      kernel domain.  Further, as init has no reason to ever set the
      enforcing mode again, we do not need to allow setenforce to the
      init domain and this prevents reverting to permissive
      mode via an errant write by init later.  We could technically
      dontaudit the kernel setenforce access instead since the first
      call to setenforce happens while still permissive (and thus we
      never need to allow it in policy) but we allow it to more accurately
      represent what is possible.
      
      Change-Id: I617876c479666a03167b8fce270c82a8d45c7cc6
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      bf12e225
  21. Nov 08, 2013
    • Nick Kralevich's avatar
      Make kernel / init enforcing · b1d81645
      Nick Kralevich authored
      Start running in enforcing mode for kernel / init.
      This should be mostly a no-op, as the kernel / init
      is in the unconfined domain.
      
      Change-Id: I8273d936c9a4eecb50b78ae93490a4dd52f59eb6
      b1d81645
  22. Sep 05, 2013
    • Geremy Condra's avatar
      Fix more long-tail denials. · 217f8afc
      Geremy Condra authored
      For additional context-
      
      The denials related to init_tmpfs are of the form:
      
      denied  { read } for  pid=12315 comm=""dboxed_process0"" path=2F6465762F6173686D656D2F64616C76696B2D68656170202864656C6574656429 dev=""tmpfs"" ino=9464 scontext=u:r:isolated_app:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
      
      (the path above is "/dev/ashmem/dalvik-heap (deleted)")
      
      The denials related to executing things from the dalvik cache are of the form:
      
      enied  { execute } for  pid=3565 comm=""dboxed_process0"" path=""/data/dalvik-cache/system@app@Chrome.apk@classes.dex"" dev=""mmcblk0p28"" ino=105983 scontext=u:r:isolated_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
      
      The denials related to isolated_app and the init socket are:
      
      denied  { getattr } for  pid=3824 comm=""Binder_2"" path=""socket:[14059]"" dev=""sockfs"" ino=14059 scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
      
      The getopt denials for the aforementioned socket are:
      
      denied  { getopt } for  pid=3824 comm=""Binder_2"" path=""/dev/socket/dumpstate"" scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
      
      Change-Id: I3c57702e2af5a779a7618da9aa40930e7f12ee49
      217f8afc
  23. Jul 11, 2013
    • Nick Kralevich's avatar
      domain.te: Add backwards compatibility for unlabeled files · 0c9708b2
      Nick Kralevich authored
      For unlabeled files, revert to DAC rules. This is for backwards
      compatibility, as files created before SELinux was in place may
      not be properly labeled.
      
      Over time, the number of unlabeled files will decrease, and we can
      (hopefully) remove this rule in the future.
      
      To prevent inadvertantly introducing the "relabelto" permission, add
      a neverallow domain, and add apps which have a legitimate need to
      relabel to this domain.
      
      Bug: 9777552
      Change-Id: I71b0ff8abd4925432062007c45b5be85f6f70a88
      0c9708b2
  24. May 15, 2013
  25. Jan 04, 2012
Loading