Prevent app domains (processes spawned by zygote) from acquiring
locks on files in /system. In particular, /system/etc/xtables.lock
must never be lockable by applications, as it will block future
iptables commands from running.
Test: device boots and no obvious problems.
Change-Id: Ifd8dc7b117cf4a622b30fd4fffbcab1b76c4421b
Apps should be able to access the configstore HAL since framework
libraries which are loaded into app process can call configstore.
Letting apps have direct access to this HAL is OK because:
(1) the API of this HAL does not make clients provide any sensitive
information to the HAL, which makes it impossible for the HAL to
disclose sensitive information of its clients when the HAL is
compromised,
(2) we will require that this HAL is binderized (i.e., does not run
inside the process of its clients),
(3) we will require that this HAL runs in a tight seccomp sandbox
(this HAL doesn't need much access, if at all) and,
(4) we'll restrict the HALs powers via neverallows.
Test: apps can use configstore hal.
Change-Id: I04836b7318fbc6ef78deff770a22c68ce7745fa9
This switches Allocator HAL policy to the design which enables us to
identify all SELinux domains which host HALs and all domains which are
clients of HALs.
Allocator HAL is special in the sense that it's assumed to be always
binderized. As a result, rules in Camera HAL target hal_allocator_server
rather than hal_allocator (which would be the server and any client, if
the Allocator HAL runs in passthrough mode).
Test: Device boots up, no new denials
Test: YouTube video plays back
Test: Take photo using Google Camera app, recover a video, record a slow
motion video
Bug: 34170079
Change-Id: Ifbbca554ec221712361ee6cda94c82f254d84936
Every client of Graphics Allocator HAL needs permission to (Hw)Binder
IPC into the HAL.
Test: Device boots, no denials to do with hal_graphics_allocator
(also, removing the binder_call(hal_graphics_allocator_client,
hal_graphics_allocator_server) leads to denials)
Test: GUI works, YouTube works
Bug: 34170079
Change-Id: I5c64d966862a125994dab903c2eda5815e336a94
This switches Boot Control HAL policy to the design which enables us
to conditionally remove unnecessary rules from domains which are
clients of Boot Control HAL.
Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control HAL
runs in passthrough mode (i.e., inside the client's process). When the
HAL runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting
hal_bootctl are not granted to client domains.
Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.
P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.
Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
1. make dist
2. Ensure device has network connectivity
3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf
This switches most remaining HALs to the _client/_server approach.
To unblock efforts blocked on majority of HALs having to use this
model, this change does not remove unnecessary rules from clients of
these HALs. That work will be performed in follow-up commits. This
commit only adds allow rules and thus does not break existing
functionality.
The HALs not yet on the _client/_server model after this commit are:
* Allocator HAL, because it's non-trivial to declare all apps except
isolated apps as clients of this HAL, which they are.
* Boot HAL, because it's still on the non-attributized model and I'm
waiting for update_engine folks to answer a couple of questions
which will let me refactor the policy of this HAL.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: Device boots in recovery mode, no new denials
Bug: 34170079
Change-Id: I03e6bcec2fa02f14bdf17d11f7367b62c68a14b9
Test: take a screenshot
Test: run CTS ImageReaderTest
Bug: 36194109
(cherry picked from commit 49ed0cd658)
Change-Id: I331bce37b35e30084ba9f7ecd063a344a79c5232
This change defines new policy for modprobe (/sbin/modprobe) that should
be used in both recovery and android mode.
Denials:
[ 16.986440] c0 437 audit: type=1400 audit(6138546.943:5): avc:
denied { read } for pid=437 comm="modprobe" name="modules" dev="proc"
ino=4026532405 scontext=u:object_r:modprobe:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=1
[ 16.986521] c0 437 audit: type=1400 audit(6138546.943:6): avc:
denied { open } for pid=437 comm="modprobe" path="/proc/modules"
dev="proc" ino=4026532405 scontext=u:object_r:modprobe:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=1
[ 16.986544] c0 437 audit: type=1400 audit(6138546.943:7): avc:
denied { getattr } for pid=437 comm="modprobe" path="/proc/modules"
dev="proc" ino=4026532405 scontext=u:object_r:modprobe:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=1
Bug: 35633646
Test: Build and tested it works in sailfish recovery. The modprobe is
invoked in init.rc (at the end of 'on init') with following command line
exec u:r:modprobe:s0 -- /sbin/modprobe -a nilfs2 ftl
Change-Id: Ie70be6f918bea6059f806e2eb38cd48229facafa
Test: no log spam for graphics allocator
Test: dmesg | audit2allow does not show denial for
hal_graphics_allocator_default
Test: system is responsive after boot (because
android.hardware.graphics.allocator@2.0::IAllocator getService()
will not be blocked)
Bug: 36220026
Change-Id: I3e103f88988fe4a94888e92ee8c5b1f27845ad9e
This switches Sensors HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Sensors HAL.
Domains which are clients of Sensors HAL, such as system_server, are
granted rules targeting hal_sensors only when the Sensors HAL runs in
passthrough mode (i.e., inside the client's process). When the HAL
runs in binderized mode (i.e., in another process/domain, with clients
talking to the HAL over HwBinder IPC), rules targeting hal_sensors are
not granted to client domains.
Domains which offer a binderized implementation of Sensors HAL, such
as hal_sensors_default domain, are always granted rules targeting
hal_sensors.
P. S. This commit also removes
allow system_server sensors_device:chr_file rw_file_perms
because this is device-specific and thus not needed in device-agnostic
policy. The device-specific policy of the affected devices already has
this rule.
Test: Device boots, no new denials
Test: adb shell dumpsys sensorservice
lists tons of sensors
Test: Proprietary sensors test app indicates that there are sensors
and that the app can register to listen for updates for sensors
and that such updates arrive to the app.
Bug: 34170079
Change-Id: I61bf779070eabcb64ae73724d62b6e837319a668
perf_event_max_sample_rate is needed to be read for native profiling,
otherwise CTS test can fail on devices with kernel >= 4.4. Before this CL,
the file is not readable from untrusted_app domain. This CL makes it readable
from both shell domain and untrusted_app domain.
Bug: http://b/35554543
Test: build and test on marlin.
Change-Id: Id118e06e3c800b70a749ab112e07a4ec24bb5975
We simplified the way we track whether or not a dex file is used by
other apps. DexManager in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: I464ed6b09439cf0342020ee07596f9aa8ae53b62
Note: The existing rules allowing socket communication will be removed
once we migrate over to HIDL completely.
(cherry-pick of 2a9595ede2)
Bug: 34603782
Test: Able to connect to wifi networks.
Test: Will be sending for full wifi integration tests
(go/wifi-test-request)
Change-Id: I9ee238fd0017ec330f6eb67ef9049211f7bd4615
We need more time to investigate the effect that this change will
have on DRM solutions. Until the investigation is done, revert.
This reverts commit 38d3eca0d4.
Bug: 30146890
Bug: 20013628
Bug: 35323421
Change-Id: I5ad69ef5ee12081ce7fc0a8440712f7f8f77cf16
Test: policy compiles.
Add FD accessing rules related to media,gralloc and ashmem.
Also move a few rules to where they belong.
Change-Id: I0bff6f86665a8a049bd767486275740fa369da3d
Drop support for execmod (aka text relocations) for newer API versions.
Retain it for older app APIs versions.
Bug: 30146890
Bug: 20013628
Bug: 35323421
Test: policy compiles.
Change-Id: Ie54fdb385e9c4bb997ad6fcb6cff74f7e32927bb
- necessary for analyzing early boot stage
bug: 35949319
Test: check captured bugreport for ro.boottime.* in SYSTEM PROPERTIES
Change-Id: I8826abd19ac00f169841b4a7ceeb68be3405d1b9
Label /proc/misc and allow access to untrusted_apps targeting older API
versions, as well as update_engine_common.
/proc/misc is used by some banking apps to try to detect if they are
running in an emulated environment.
TODO: Remove access to proc:file from update_engine_common after more
testing.
Bug: 35917228
Test: Device boots and no new denials.
Change-Id: If1b97a9c55a74cb74d1bb15137201ffb95b5bd75
The new wifi HAL manages the wlan driver and hence needs to be able to
load/unload the driver. The "wlan.driver.status" is used to indicate the
state of the driver to the rest of the system. There are .rc scripts for
example which wait for the state of this property.
Denials:
03-01 13:31:43.394 476 476 W android.hardwar: type=1400
audit(0.0:7243): avc: denied { read } for name="u:object_r:wifi_prop:s0"
dev="tmpfs" ino=10578 scontext=u:r:hal_wifi_default:s0
tcontext=u:object_r:wifi_prop:s0 tclass=file permissive=0
03-01 13:31:43.399 476 476 E libc : Access denied finding
property "wlan.driver.status"
Bug: 35765841
Test: Denials no longer seen
Change-Id: I502494af7140864934038ef51cb0326ba3902c63
This starts with the reduction in the number of services that
ephemeral apps can access. Prior to this commit, ephemeral apps were
permitted to access most of the service_manager services accessible
by conventional apps. This commit reduces this set by removing access
from ephemeral apps to:
* gatekeeper_service,
* sec_key_att_app_id_provider_service,
* wallpaper_service,
* wifiaware_service,
* wifip2p_service,
* wifi_service.
Test: Device boots up fine, Chrome, Play Movies, YouTube, Netflix, work fine.
Bug: 33349998
Change-Id: Ie4ff0a77eaca8c8c91efda198686c93c3a2bc4b3
- compared to ro.boottime, this one does not pass time info
bug: 35178781
bug: 34274385
Test: reboot
Change-Id: I6a7bf636a3f201653e2890751d5fa210274c9ede
Add a file context for keeping track of last reboot reason and label
directory /data/misc/reboot/ for this purpose.
(Cherry picked from commit ca051f6d07)
Bug: 30994946
Test: manual: reboot ocmmand, setprop sys.powerctl, SoC thermal mgr
Change-Id: I9569420626b4029a62448b3f729ecbbeafbc3e66
Bug: 35328775
Test: works in both binderized and passthrough modes
Merged-In: I1f827b4983e5e67c516e4488ad3497dd62db7e20
Change-Id: I1f827b4983e5e67c516e4488ad3497dd62db7e20
Previously, we'd restricted WifiService's use of
the kernel's tracing feature to just userdebug_or_eng
builds.
This restriction was in place because the feature
had not yet been reviewed from a privacy perspective.
Now that the feature has passed privacy review, enable
the feature on all builds.
Note that other safeguards remain in place (on all
builds):
- The set of events to be monitored is configured by
init, rather than WifiService (part of system_server).
This privilege separation prevents a compromised
system_server from tracing additional information.
- The trace events are kept only in RAM, until/unless
WifiService receives a dump request. (This would happen,
for example, in the case of adb dumpsys, or generating
a bugreport.)
Bug: 35679234
Test: manual (see below)
Manual test details:
- flash device
- connect device to a wifi network
$ adb shell dumpsys wifi | grep rdev_connect
[should see at least one matching line]
Change-Id: I85070054857d75177d0bcdeb9b2c95bfd7e3b6bc
Label /proc/sys/vm/mmap_rnd_bits so it is only readable and writable by
init. This also tightens the neverallow restrictions for proc_security.
Bug: 33563834
Test: run cts -m CtsPermissionTestCases -t \
android.permission.cts.FileSystemPermissionTest#testProcfsMmapRndBitsExistsAndSane
Change-Id: Ie7af39ddbf23806d4ffa35e7b19d30fec7b6d410
