Skip to content
Snippets Groups Projects
  1. Dec 22, 2016
    • Alex Klyubin's avatar
      Restrict access to ro.serialno and ro.boot.serialno · 20151072
      Alex Klyubin authored
      This restricts access to ro.serialno and ro.boot.serialno, the two
      system properties which contain the device's serial number, to a
      select few SELinux domains which need the access. In particular, this
      removes access to these properties from Android apps. Apps can access
      the serial number via the public android.os.Build API. System
      properties are not public API for apps.
      
      The reason for the restriction is that serial number is a globally
      unique identifier which cannot be reset by the user. Thus, it can be
      used as a super-cookie by apps. Apps need to wean themselves off of
      identifiers not resettable by the user.
      
      Test: Set up fresh GMS device, install some apps via Play, update some apps, use Chrome
      Test: Access the device via ADB (ADBD exposes serial number)
      Test: Enable MTP over USB, use mtp-detect to confirm that serial number is reported in MTP DeviceInfo
      Bug: 31402365
      Bug: 33700679
      Change-Id: I4713133b8d78dbc63d8272503e80cd2ffd63a2a7
      20151072
  2. Dec 14, 2016
    • Nick Kralevich's avatar
      Assign a label to the ro.boottime.* properties · bb9a3888
      Nick Kralevich authored
      system/core commit 331cf2fb7c16b5b25064f8d2f00284105a9b413f created a
      number of new properties of the form:
      
        [ro.boottime.init]: [5294587604]
        [ro.boottime.InputEventFind]: [10278767840]
        [ro.boottime.adbd]: [8359267180]
        ...
      
      These properties were assigned the default_prop SELinux label because a
      better label did not exist. Properties labeled with the default_prop
      label are readable to any SELinux domain, which is overly broad.
      
        bullhead:/ $ getprop -Z ro.boottime.adbd
        u:object_r:default_prop:s0
      
      Instead, create a new label for the ro.boottime.* properties so we can
      apply more fine grain read access control to these properties.
      
        bullhead:/ $ getprop -Z ro.boottime.adbd
        u:object_r:boottime_prop:s0
      
      New SELinux property labels have minimal permissions by default. As a
      result, after this change, ro.boottime.* properties will only be
      readable to system_server, bootstat, init (because it manages the property
      space), and "adb root" (because no SELinux permissions are enforced there).
      
      Additional read access can be granted as-needed.
      
      This is part of a larger effort to implement fine-grain access control
      on the properties managed by init.
      
      Test: Device boots and no SELinux denials on boot.
      Change-Id: Ibf981cb81898f4356fdc5c1b6f15dd93c0d6d84d
      bb9a3888
    • Nick Kralevich's avatar
      Do not allow new additions to core_property_type · d310df20
      Nick Kralevich authored
      core_property_type is an attribute which was given to all existing
      properties known to core SELinux policy. Any property with this label is
      readable to all SELinux domains, which is overly broad. The long term
      goal is to remove the core_property_type attribute entirely.
      
      Add a neverallow rule prohibiting the introduction of new properties
      with the core_property_type attribute. Device specific properties, or
      new properties in core SELinux policy, should not have this attribute.
      
      Test: policy compiles
      Change-Id: Ie89a9f0d81c8561616001ff8451496ce2278dbb2
      d310df20
  3. Nov 11, 2016
    • Nick Kralevich's avatar
      property.te: delete security_prop · ee751c33
      Nick Kralevich authored
      This property is never used.
      
      Test: policy compiles
      Change-Id: I43ace92950e1221754db28548031fbbfc0437d7a
      ee751c33
    • Nick Kralevich's avatar
      property.te: sort entries · 26c6d726
      Nick Kralevich authored
      Sort the entries in property.te. This will make it slightly easier to
      read, and avoids merge conflicts by discouraging the common practice of
      adding entries to the bottom of this file.
      
      Test: policy compiles.
      Change-Id: I87ae96b33156dba73fb7eafc0f9a2a961b689853
      26c6d726
  4. Nov 10, 2016
    • Jason Monk's avatar
      Add persist.vendor.overlay. to properties · 0e1cbf56
      Jason Monk authored
      Allow the system_server to change. Allow the zygote to read it as well.
      
      Test: Have system_server set a property
      Change-Id: Ie90eec8b733fa7193861026a3a6e0fb0ba5d5318
      0e1cbf56
  5. Oct 06, 2016
    • dcashman's avatar
      Split general policy into public and private components. · cc39f637
      dcashman authored
      Divide policy into public and private components.  This is the first
      step in splitting the policy creation for platform and non-platform
      policies.  The policy in the public directory will be exported for use
      in non-platform policy creation.  Backwards compatibility with it will
      be achieved by converting the exported policy into attribute-based
      policy when included as part of the non-platform policy and a mapping
      file will be maintained to be included with the platform policy that
      maps exported attributes of previous versions to the current platform
      version.
      
      Eventually we would like to create a clear interface between the
      platform and non-platform device components so that the exported policy,
      and the need for attributes is minimal.  For now, almost all types and
      avrules are left in public.
      
      Test: Tested by building policy and running on device.
      
      Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
      cc39f637
  6. Sep 26, 2016
  7. Sep 21, 2016
    • Felipe Leme's avatar
      Let system_server writes to dumpstate.options property. · a5a8072f
      Felipe Leme authored
      Currently, we define 4 hardcoded init services to launch dumpstate with
      different command-line options (since dumpstate must be launched by
      root):
      
      - bugreport
      - bugreportplus
      - bugreportwear
      - bugreportremote
      
      This approach does not scale well; a better option is to have just one
      service, and let the framework pass the extra arguments through a system
      property.
      
      BUG: 31649719
      Test: manual
      
      Change-Id: I7ebbb7ce6a0fd3588baca6fd76653f87367ed0e5
      a5a8072f
  8. Sep 12, 2016
  9. Aug 26, 2016
    • Christopher Wiley's avatar
      Separate permissions to set WiFi related properties · bf18eca5
      Christopher Wiley authored
      wificond would like to be able to set WiFi related properties
      without access to the rest of the system properties.  Today,
      this only involves marking the driver as loaded or unloaded.
      
      avc: denied { write } for name="property_service" dev="tmpfs" ino=10100
      scontext=u:r:wificond:s0 tcontext=u:object_r:property_socket:s0
      tclass=sock_file permissive=0
      
      Bug: 29579539
      Test: No avc denials related to system properties across
            various WiFi events.
      
      Change-Id: I6d9f1de3fbef04cb7750cc3753634f9e02fdb71f
      (cherry picked from commit 1ebfdd6a)
      bf18eca5
  10. Jul 14, 2016
  11. Jun 28, 2016
  12. Jun 07, 2016
  13. Jun 03, 2016
  14. Apr 19, 2016
    • mukesh agrawal's avatar
      allow system server to set log.tag.WifiHAL · e651f6f4
      mukesh agrawal authored
      On eng and userdebug builds (only), allow system server
      to change the value of log.tag.WifiHAL. WifiStateMachine
      will set this property to 'D' by default. If/when a user
      enables "Developer options -> Enable Wi-Fi Verbose Logging",
      WifiStateMachine change log.tag.WifiHAL to 'V'.
      
      BUG=27857554
      TEST=manual (see below)
      
      Test detail
      1. on user build:
         $ adb shell setprop log.tag.WifiHAL V
         $ adb shell getprop log.tag.WifiHAL
         <blank line>
         $ adb bugreport | grep log.tag.WifiHAL
         <11>[  141.918517] init: avc:  denied  { set } for property=log.tag.WifiHAL pid=4583 uid=2000 gid=2000 scontext=u:r:shell:s0 tcontext=u:object_r:wifi_log_prop:s0 tclass=property_service permissive=0
         <11>[  141.918566] init: sys_prop: permission denied uid:2000  name:log.tag.WifiHAL
      2. on userdebug build:
         $ adb shell getprop log.tag.WifiHAL
         $ <blank line>
         $ adb shell setprop log.tag.WifiHAL V
         $ adb shell getprop log.tag.WifiHAL
         V
      3. on userdebug build with modified WifiStateMachine:
         $ adb shell getprop log.tag.WifiHAL
         D
      
      Change-Id: I9cdd52a2b47a3dd1065262ea8c329130b7b044db
      e651f6f4
    • mukesh agrawal's avatar
      limit shell's access to log.* properties · 84cfde22
      mukesh agrawal authored
      Restrict the ability of the shell to set the log.*
      properties. Namely: only allow the shell to set
      such properities on eng and userdebug builds.
      
      The shell (and other domains) can continue to
      read log.* properties on all builds.
      
      While there: harmonize permissions for log.* and
      persist.log.tag. Doing so introduces two changes:
      - log.* is now writable from from |system_app|. This
        mirrors the behavior of persist.log.tag, which is
        writable to support "Developer options" ->
        "Logger buffer sizes" -> "Off".
        (Since this option is visible on user builds, the
        permission is enabled for all builds.)
      - persist.log.tag can now be set from |shell| on
        userdebug_or_eng().
      
      BUG=28221972
      TEST=manual (see below)
      
      Testing details
      - user build (log.tag)
        $ adb shell setprop log.tag.foo V
        $ adb shell getprop log.tag
        <blank line>
        $ adb bugreport | grep log.tag.foo
        [  146.525836] init: avc:  denied  { set } for property=log.tag.foo pid=4644 uid=2000 gid=2000 scontext=u:r:shell:s0 tcontext=u:object_r:log_prop:s0 tclass=property_service permissive=0
        [  146.525878] init: sys_prop: permission denied uid:2000  name:log.tag.foo
      - userdebug build (log.tag)
        $ adb shell getprop log.tag.foo
        <blank line>
        $ adb shell setprop log.tag.foo V
        $ adb shell getprop log.tag.foo
        V
      - user build (persist.log.tag)
        $ adb shell getprop | grep log.tag
        <no match>
        - Developer options -> Logger buffer sizes -> Off
        $ adb shell getprop | grep log.tag
        [persist.log.tag]: [Settings]
        [persist.log.tag.snet_event_log]: [I]
      
      Change-Id: Idf00e7a623723a7c46bf6d01e386aeca92b2ad75
      84cfde22
  15. Mar 24, 2016
  16. Feb 22, 2016
  17. Feb 10, 2016
  18. Feb 04, 2016
  19. Jan 19, 2016
    • Rubin Xu's avatar
      SELinux rule for ro.device_owner and persist.logd.security · 0c8286fe
      Rubin Xu authored
      They are introduced for the device owner process logging feature.
      That is, for enterprise-owned devices with device owner app provisioned,
      the device owner may choose to turn on additional device-wide logging for
      auditing and intrusion detection purposes. Logging includes histories of
      app process startup, commands issued over ADB and lockscreen unlocking
      attempts. These logs will available to the device owner for analysis,
      potentially shipped to a remote server if it chooses to.
      
      ro.device_owner will be a master switch to turn off logging, if the device
      has no device owner provisioned. persist.logd.security is a switch that
      device owner can toggle (via DevicePoliyManager) to enable/disable logging.
      Writing to both properties should be only allowed by the system server.
      
      Bug: 22860162
      Change-Id: Iabfe2347b094914813b9d6e0c808877c25ccd038
      0c8286fe
  20. Dec 09, 2015
  21. Dec 08, 2015
    • Nick Kralevich's avatar
      Remove property read access for non-core properties · 5a570a4b
      Nick Kralevich authored
      Instead of allowing global read access to all properties,
      only allow read access to the properties which are part of
      core SELinux policy. Device-specific policies are no longer
      readable by default and need to be granted in device-specific
      policy.
      
      Grant read-access to any property where the person has write
      access. In most cases, anyone who wants to write a property
      needs read access to that property.
      
      Change-Id: I2bd24583067b79f31b3bb0940b4c07fc33d09918
      5a570a4b
  22. Dec 04, 2015
    • Felipe Leme's avatar
      Increase communication surface between dumpstate and Shell: · 83fd8a54
      Felipe Leme authored
      - Add a new 'dumpstate' context for system properties. This context
        will be used to share state between dumpstate and Shell. For example,
        as dumpstate progresses, it will update a system property, which Shell
        will use to display the progress in the UI as a system
        notification. The user could also rename the bugreport file, in which
        case Shell would use another system property to communicate such
        change to dumpstate.
      - Allow Shell to call 'ctl.bugreport stop' so the same system
        notification can be used to stop dumpstate.
      
      BUG: 25794470
      
      Change-Id: I74b80bda07292a91358f2eea9eb8444caabc5895
      83fd8a54
  23. Dec 03, 2015
    • Tom Cherry's avatar
      Support fine grain read access control for properties · 949d7cbc
      Tom Cherry authored
      Properties are now broken up from a single /dev/__properties__ file into
      multiple files, one per property label.  This commit provides the
      mechanism to control read access to each of these files and therefore
      sets of properties.
      
      This allows full access for all domains to each of these new property
      files to match the current permissions of /dev/__properties__.  Future
      commits will restrict the access.
      
      Bug: 21852512
      
      Change-Id: Ie9e43968acc7ac3b88e354a0bdfac75b8a710094
      949d7cbc
  24. Jul 30, 2015
  25. Jun 09, 2015
    • Jeff Sharkey's avatar
      New "selinux.restorecon" control property. · 7617cd48
      Jeff Sharkey authored
      This new property is used as a control verb for running a recursive
      restorecon at the path contained in the property value.
      
      Defines a new label and grants access to vold, which invokes it when
      mounting private adopted volumes.
      
      Bug: 21121357
      Change-Id: I8ff12a146e54a505aa5b43a542578891563d647a
      7617cd48
  26. Apr 24, 2015
  27. Feb 27, 2015
  28. Feb 18, 2015
    • Sami Tolvanen's avatar
      Allow ueventd to set verity.* properties · 47cd53a5
      Sami Tolvanen authored
      On dm-verity errors, we catch uevents in ueventd and set the value
      for a matching verity.* property. Allow ueventd to actually change
      property values.
      
      Needed by changes from
        Ibb82953594d234f81ad21c40f524190b88e4ac8f
      
      Change-Id: I79bc90733edf8a45b27e64795f4adfbb3bc028dc
      47cd53a5
  29. Nov 19, 2014
  30. Nov 18, 2014
  31. Sep 28, 2014
    • Stephen Smalley's avatar
      Dependencies for new goldfish service domains. · 54e9bc45
      Stephen Smalley authored
      
      In order to support the new goldfish service domains in
      a change with the same Change-Id for the build project, we need
      the following changes in external/sepolicy:
      - /system/bin/logcat needs its own type so that it can be used as an
      entrypoint for the goldfish-logcat service.  A neverallow rule prevents
      us from allowing entrypoint to any type not in exec_type.
      - The config. and dalvik. property namespaces need to be labeled
      with something other than default_prop so that the qemu-props
      service can set them.  A neverallow rule prevents us from allowing
      qemu-props to set default_prop.
      
      We allow rx_file_perms to logcat_exec for any domain that
      was previously allowed read_logd() as many programs will read
      the logs by running logcat.  We do not do this for all domains
      as it would violate a neverallow rule on the kernel domain executing
      any file without transitioning to another domain, and as we ultimately
      want to apply the same restriction to the init domain (and possibly others).
      
      Change-Id: Idce1fb5ed9680af84788ae69a5ace684c6663974
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      54e9bc45
Loading