Property being set: sys.boot_from_charger_mode. If healthd attempts to write
this property without the policy changes we get the following audit message:
[ 45.751195] type=1400 audit(1403556447.444:7): avc: denied { write } for pid=99 comm="charger" name="property_service" dev="tmpfs" ino=3229 scontext=u:r:healthd:s0 tcontext=u:object_r:property_socket:s0 tclass=sock_file permissive=0
These changes are needed to support the following system/core commit:
faster booting from charger mode
* Ieec4494d929e92806e039f834d78b9002afd15c4
Change-Id: I9f198cd73c7b2f1e372c3793dc2b8d5ef26b3a0f
Add a service_mananger class with the verb add.
Add a type that groups the services for each of the
processes that is allowed to start services in service.te
and an attribute for all services controlled by the service
manager. Add the service_contexts file which maps service
name to target label.
Bug: 12909011
Change-Id: I017032a50bc90c57b536e80b972118016d340c7d
As of sepolicy commit a16a59e2c7
(https://android-review.googlesource.com/94580), adf_device
and graphics_device have the exact same security properties.
Merge them into one type to avoid a proliferation of SELinux
types.
Change-Id: Ib1a24f5d880798600e103b9e14934e41abb1ef95
Introduce wakelock_use(). This macro declares that a domain uses
wakelocks.
Wakelocks require both read-write access to files in /sys/power, and
CAP_BLOCK_SUSPEND. This macro helps ensure that both capabilities and
file access are granted at the same time.
Still TODO: fix device specific wakelock use.
Change-Id: Ib98ff374a73f89e403acd9f5e024988f59f08115
ADF is a modern replacement for fbdev.
ADF's device nodes (/dev/adf[X]), interface nodes
(/dev/adf-interface[X].[Y]), and overlay engine nodes
(/dev/adf-overlay-engine[X].[Y]) are collectively used in similar
contexts as fbdev nodes. Vendor HW composers (via SurfaceFlinger) and
healthd will need to send R/W ioctls to these nodes to prepare and
update the display.
Ordinary apps should not talk to ADF directly.
Change-Id: Ic0a76b1e82c0cc1e8f240f219928af1783e79343
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Reboots/halts aren't working in healthd charger mode. This is
causing high power draw in an unplugged, powered off state.
Steps to reproduce (on Nexus 5):
Unplug device from USB charger/computer
Turn device off
Wait for device to turn off
Plug in USB cable/charger
Wait for charge animation (wait for animation, not just lightning bolt, may have to press power button briefly to get animation going)
Wait for panel to turn off
Unplug USB cable/charger
Press power button again, notice screen turns on at some frame in the animation.
(not important) Each press of the power button advances the animation
Power on.
Examine denials from /proc/last_kmsg
Addresses the following denials:
[ 24.934809] type=1400 audit(12534308.640:8): avc: denied { write } for pid=130 comm="healthd" name="sysrq-trigger" dev="proc" ino=4026533682 scontext=u:r:healthd:s0 tcontext=u:object_r:proc_sysrq:s0 tclass=file
[ 24.935395] type=1400 audit(12534308.640:9): avc: denied { sys_boot } for pid=130 comm="healthd" capability=22 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability
Bug: 13229119
Change-Id: If14a9c373bbf156380a34fbd9aca6201997d5553
healthd performs privileged ioctls on the tty device
when in charger mode. Allow it.
This fixes a bug where off charging mode is forcing the device
to reboot into recovery.
Addresses the following denial:
type=1400 audit(15080631.900:4): avc: denied { sys_tty_config } for pid=130 comm="healthd" capability=26 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability
Bug: 13472365
Change-Id: I402987baf62ba0017e79e30e370850c32c286a6a
Healthd has an optional "charger" mode. The device boots into a
minimally running mode, and healthd displays the battery indicator.
Without this patch, when a manta device boots into charger mode,
the screen will never turn off and the battery indicator will not move.
From reviewing the healthd code, it looks like this may affect lots
of devices, not just manta. I'm adding this change to the generic
policy.
Steps to reproduce:
1) Make sure the device is unplugged.
2) Boot into a normal system.
3) Shutdown the system normally using the power button.
4) After shutdown, plugin the power cord.
5) Device will boot into charger mode. Battery icon will display.
6) Press the button to reboot into a normal mode.
7) Examine /proc/last_kmsg and look for denials.
Addresses the following denials:
[ 3.908457] type=1400 audit(1390866386.620:3): avc: denied { read write } for pid=98 comm="charger" name="fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[ 3.909085] type=1400 audit(1390866386.620:4): avc: denied { open } for pid=98 comm="charger" name="fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[ 3.909749] type=1400 audit(1390866386.620:5): avc: denied { ioctl } for pid=98 comm="charger" path="/dev/graphics/fb0" dev="tmpfs" ino=4286 scontext=u:r:healthd:s0 tcontext=u:object_r:graphics_device:s0 tclass=chr_file
[ 4.889857] type=1400 audit(1390866387.605:6): avc: denied { read } for pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[ 4.890873] type=1400 audit(1390866387.605:7): avc: denied { open } for pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[ 4.891949] type=1400 audit(1390866387.605:8): avc: denied { search } for pid=98 comm="charger" name="input" dev="tmpfs" ino=4153 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=dir
[ 4.892677] type=1400 audit(1390866387.605:9): avc: denied { read } for pid=98 comm="charger" name="event2" dev="tmpfs" ino=4279 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file
[ 4.893576] type=1400 audit(1390866387.605:10): avc: denied { open } for pid=98 comm="charger" name="event2" dev="tmpfs" ino=4279 scontext=u:r:healthd:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file
[ 7.288104] type=1400 audit(1390866389.999:12): avc: denied { execmem } for pid=98 comm="charger" scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=process
[ 7.288574] type=1400 audit(1390866389.999:13): avc: denied { execute } for pid=98 comm="charger" path="/dev/ashmem" dev="tmpfs" ino=4113 scontext=u:r:healthd:s0 tcontext=u:object_r:ashmem_device:s0 tclass=chr_file
Change-Id: I0118e08514caa0ad11d2aa7562c9846a96779a21
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
The kernel bug that required healthd to remain permissive was fixed by
I8a3e0db15ec5f4eb05d455a57e8446a8c2b484c2.
Change-Id: Iff07b65b943cadf949d9b747376a8621b2378bf8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
init creates a private /dev/null instance named /dev/__null__
that is inherited by healthd. Since it is created prior to
initial policy load, it is left in the tmpfs type.
Allow healthd to inherit and use the open fd.
Change-Id: I525fb4527766d0780457642ebcc19c0fcfd1778c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add the necessary rules to support dumpstate.
Start off initially in permissive until it has more testing.
Dumpstate is triggered by running "adb bugreport"
Change-Id: Ic17a60cca1f6f40daa4f2c51e9ad6009ef36cfbd
This change removes the permissive line from unconfined
domains. Unconfined domains can do (mostly) anything, so moving
these domains into enforcing should be a no-op.
The following domains were deliberately NOT changed:
1) kernel
2) init
In the future, this gives us the ability to tighten up the
rules in unconfined, and have those tightened rules actually
work.
When we're ready to tighten up the rules for these domains,
we can:
1) Remove unconfined_domain and re-add the permissive line.
2) Submit the domain in permissive but NOT unconfined.
3) Remove the permissive line
4) Wait a few days and submit the no-permissive change.
For instance, if we were ready to do this for adb, we'd identify
a list of possible rules which allow adbd to work, re-add
the permissive line, and then upload those changes to AOSP.
After sufficient testing, we'd then move adb to enforcing.
We'd repeat this for each domain until everything is enforcing
and out of unconfined.
Change-Id: If674190de3262969322fb2e93d9a0e734f8b9245
