Skip to content
Snippets Groups Projects
  1. 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
  2. Mar 11, 2015
    • Nick Kralevich's avatar
      system_server: neverallow blk_file read/write · acc0842c
      Nick Kralevich authored
      With the exception of the factory reset protection block device,
      don't allow system_server to read or write to any other block
      devices. This helps protect against a system->root escalation
      when system_server has the ability to directly minipulate raw
      block devices / partitions / partition tables.
      
      This change adds a neverallow rule, which is a compile time
      assertion that no SELinux policy is written which allows this
      access. No new rules are added or removed.
      
      Change-Id: I388408423097ef7cf4950197b79d4be9d666362c
      acc0842c
  3. Nov 05, 2014
    • Nick Kralevich's avatar
      recovery.te: add /data neverallow rules · a17a266e
      Nick Kralevich authored
      Recovery should never be accessing files from /data.
      In particular, /data may be encrypted, and the files within
      /data will be inaccessible to recovery, because recovery doesn't
      know the decryption key.
      
      Enforce write/execute restrictions on recovery. We can't tighten
      it up further because domain.te contains some /data read-only
      access rules, which shouldn't apply to recovery but do.
      
      Create neverallow_macros, used for storing permission macros
      useful for neverallow rules. Standardize recovery.te and
      property_data_file on the new macros.
      
      Change-Id: I02346ab924fe2fdb2edc7659cb68c4f8dffa1e88
      a17a266e
Loading