Commit graph

8 commits

Author SHA1 Message Date
Tri Vo
b1affc9095 Remove bootstat access to proc label.
Bug: 65643247
Test: device boots without denials from bootstat to proc.
Change-Id: Ie31a0488239dbb1614fbcce07540d23afa805b0e
2017-09-18 10:29:24 -07:00
Mark Salyzyn
397b07b38f bootstat: lock down *_boot_reason_prop
Add series of neverallow rules to restrict components from reading or
writing bootloader_boot_reason_prop, system_boot_reason_prop and
last_boot_reason_prop to trusted set of domains.

The policy is that bootloader_boot_reason_prop (ro.boot.bootreason)
has a compliance issue due to the sheer momentum of near unparseable
content as filed by the wide variety (8000 different devices at last
count) bootloaders and is only to be accessible to a series of
responsible system components.  It can be inaccurate as it provides
no means to evaluate a shutdown, likely reporting "cold" (from
initial power up) or the more generic "reboot".

The last_boot_reason_prop (persist.sys.boot.reason) contains
inaccurate information as it is only valid after a controlled reboot
or shutdown.  The value can linger around after less controlled
scenarios.  Since the information could be false, we do not want to
support it as an open API, so we again block access to only
responsible components.

The system_boot_reason_prop (sys.boot.reason) is a canonical boot
reason that takes into account parsing bootloader_boot_reason_prop,
boot_loader_boot_reason_prop and other system and HAL generated hints
to determine a parseable and most accurate reason for the last time
the system was rebooted.

For now the policy for system_boot_reason_prop is to audit users of
the API, and on a need to know basis via device additions to the
selinux rules.  If vendors need their components to access the boot
reason, they need to comply first with CTS tests and spirit with
regards to controlled reboot messaging and in turn read the
system_boot_reason_prop for the canonical information.  It will
contain validated content derived from bootloader_boot_reason_prop
in the scenarios that count.

The controlled reboot APIs include:
- android_reboot(ANDROID_RB_<TYPE>, int flag, const char* reason)
- PowerManagerService.lowLevelShutdown(String reason);
- PowerManagerService.lowLevelReboot(String reason);
- ShutdownThread.shutdown(context, String reason, boolean confirm);
- ShutdownThread.reboot(context, String reason, boolean confirm);
- PowerManager.shutdown(boolean confirm, String reason, boolean wait);
- PowerManager.reboot(String reason);

Any others (including the direct linux reboot syscall) create
problems for generating an accurate canonical boot reason.

Test: compile
Bug: 63736262
Bug: 65686279
Change-Id: I2e5e55bbea1c383c06472eb2989237cfeb852030
2017-09-15 08:26:00 -07:00
Mark Salyzyn
801918d14a bootstat: introduce sys.boot.reason
Add access to [persist.]sys.boot.reason, pstore, dmesg and logcat

Test: system/core/bootstat/boot_reason_test.sh
Bug: 63736262
Change-Id: Id521609308e0e967b24d7558982b30a1fc4c0a32
2017-08-24 15:19:40 -07:00
Mark Salyzyn
006c2e9934 Switch /data/misc/reboot/last_reboot_reason to persistent property
Switch from /data/misc/reboot/last_reboot_reason to persistent
Android property persist.sys.boot.reason for indicating why the
device is rebooted or shutdown.

Introduce protection for all boot reason properties

Protect the following properties with these labels

ro.boot.bootreason      u:object_r:bootloader_boot_reason_prop:s0
sys.boot.reason         u:object_r:sys_boot_reason_prop:s0
persist.sys.boot.reason u:object_r:last_boot_reason_prop:s0

Setup the current as-need access rules for each.

ToDo: Remove u:object_r:reboot_data_file after internal fixes.

Test: system/core/bootstat/boot_reason_test.sh
Bug: 64687998
Change-Id: I3771c73933e8ae2d94aee936c7a38b6282611b80
2017-08-24 15:19:30 -07:00
Mark Salyzyn
d33a9a194b logd: restrict access to /dev/event-log-tags
Create an event_log_tags_file label and use it for
/dev/event-log-tags.  Only trusted system log readers are allowed
direct read access to this file, no write access.  Untrusted domain
requests lack direct access, and are thus checked for credentials via
the "plan b" long path socket to the event log tag service.

Test: gTest logd-unit-tests, liblog-unit-tests and logcat-unit-tests
Bug: 31456426
Bug: 30566487
Change-Id: Ib9b71ca225d4436d764c9bc340ff7b1c9c252a9e
2017-01-31 15:50:15 +00:00
Nick Kralevich
bb9a388840 Assign a label to the ro.boottime.* properties
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
2016-12-14 13:45:01 -08:00
Nick Kralevich
b56e6ef894 Whitespace fix
Because I'm nitpicky.

Test: policy compiles
Change-Id: I4d886d0d6182d29d7b260cf1f142c47cd32eda29
2016-12-09 20:14:31 -08: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 bootstat.te (Browse further)