Commit graph

7 commits

Author SHA1 Message Date
Alex Light
16dfb432b3 Use postinstall file_contexts
Previously we would mount OTA images with a 'context=...' mount
option. This meant that all selinux contexts were ignored in the ota
image, limiting the usefulness of selinux in this situation. To fix
this the mount has been changed to not overwrite the declared contexts
and the policies have been updated to accurately describe the actions
being performed by an OTA.

Bug: 181182967
Test: Manual OTA of blueline
Merged-In: I5eb53625202479ea7e75c27273531257d041e69d
Change-Id: I5eb53625202479ea7e75c27273531257d041e69d
2021-03-24 17:00:35 -07:00
Andreas Gampe
d6fdcefaa8 Sepolicy: Move otapreopt_chroot to private
Move complete domain to private/. Move referencing parts in domain
and kernel to private.

Bug: 128840749
Test: m
Change-Id: I5572c3b04e41141c8f4db62b1361e2b392a5e2da
2019-03-18 10:54:42 -07:00
Roland Levillain
66fcb98464 Clean up APEX-related otapreopt_chroot policies.
Test: A/B OTA update test (asit/dexoptota/self_full).
Bug: 113373927
Bug: 120796514
Change-Id: Icbbe1babe0dceebff2546264ddabe779babba761
2019-01-25 14:36:37 +00:00
Roland Levillain
0a6c2d013a Allow otapreopt_chroot to mount APEX packages using apexd logic.
Allow `otapreopt_chroot` to:
- read SELinux policy files;
- open and read the contents of `/postinstall/system/apex`;
- read the `persist.apexd.verity_on_system` system property;
- create loop devices with `/dev/loop-control`;
- access loop devices;
- configure read-ahead of loop devices;
- mount a tmpfs filesystem in `/postinstall/apex`;
- manipulate the tmpfs filesystem mounted in `/postinstall/apex`;
- mount APEX packages in `/postinstall/apex`.

Allow the kernel to:
- read `otapreopt_chroot`'s file descriptors;
- read files under `/postinstall`.

Allow `otapreopt` (running as "postinstall_dexopt") to:
- read data from `/postinstall/apex`.

Allow `dex2oat` to:
- access `/postinstall/apex`.

Test: A/B OTA update test (asit/dexoptota/self_full).
Bug: 113373927
Bug: 120796514
Change-Id: I204df92611dc710fdc97b22cd67d088ffd991210
2019-01-17 21:42:46 +00:00
Nick Kralevich
5e37271df8 Introduce system_file_type
system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.

Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.

Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
2018-09-27 12:52:09 -07:00
Benjamin Gordon
9b2e0cbeea sepolicy: Add rules for non-init namespaces
In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.

This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.

This is essentially:
  1. New global_capability_class_set and global_capability2_class_set
     that match capability+cap_userns and capability2+cap2_userns,
     respectively.
  2. s/self:capability/self:global_capability_class_set/g
  3. s/self:capability2/self:global_capability2_class_set/g
  4. Add cap_userns and cap2_userns to the existing capability_class_set
     so that it covers all capabilities.  This set was used by several
     neverallow and dontaudit rules, and I confirmed that the new
     classes are still appropriate.

Test: diff new policy against old and confirm that all new rules add
      only cap_userns or cap2_userns;
      Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831

Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f
2017-11-21 08:34:32 -07:00
dcashman
cc39f63773 Split general policy into public and private components.
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
2016-10-06 13:09:06 -07:00
Renamed from otapreopt_chroot.te (Browse further)