We allow domains to manually transition to logpersist for userdebug
or eng debug logging permissions that would be counter to monitoring
limits on a released user build.
Test: compile
Bug: 30566487
Change-Id: I03a81c75cbd2b44617e4b27c4c083a26a0e0fa87
6e4508e625 inadvertently removed access
to ro.serialno and ro.boot.serialno from ADB shell. This is needed for
CTS. This commit thus reinstates the access.
Test: adb shell getprop ro.serialno
Bug: 33700679
Change-Id: I62de44b1631c03fcd64ceabaf33bbaeb869c2851
This removes access to Bluetooth system properties from arbitrary
SELinux domains. Access remains granted to init, bluetooth, and
system_app domains. neverallow rules / CTS enforce that access is not
granted to Zygote and processes spawned from Zygote expcept for
system_app and bluetooth.
The reason is that some of these properties may leak persistent
identifiers not resettable by the user.
Test: Bluetooth pairing and data transfer works
Bug: 33700679
Change-Id: Icdcb3927a423c4011a62942340a498cc1b302472
ro.runtime.firstboot system property is only used internally by
system_server to distinguish between first start after boot from
consecutive starts (for example, this happens when full-disk
encryption is enabled). The value of the property is a
millisecond-precise timestamp which can help track individual
device. Thus apps should not have access to this property.
Test: Device boots fine, reading ro.runtime.firstboot from an app results in an error and SELinux denial.
Bug: 33700679
Change-Id: I4c3c26a35c5dd840bced3a3e53d071f45317f63c
SELinux policy compiler complained about a quote inside the
recovery_only section of recovery.te. This section's contents are
inside quotes and thus can't contain quotes.
Test: mmm system/sepolicy produces no warnings
Bug: 33700679
Change-Id: I5bf943166f4f514d04472f7e59b025a9723eb1b8
This restricts access to ro.serialno and ro.boot.serialno, the two
system properties which contain the device's serial number, to a
select few SELinux domains which need the access. In particular, this
removes access to these properties from Android apps. Apps can access
the serial number via the public android.os.Build API. System
properties are not public API for apps.
The reason for the restriction is that serial number is a globally
unique identifier which cannot be reset by the user. Thus, it can be
used as a super-cookie by apps. Apps need to wean themselves off of
identifiers not resettable by the user.
Test: Set up fresh GMS device, install some apps via Play, update some apps, use Chrome
Test: Access the device via ADB (ADBD exposes serial number)
Test: Enable MTP over USB, use mtp-detect to confirm that serial number is reported in MTP DeviceInfo
Bug: 31402365
Bug: 33700679
Change-Id: I4713133b8d78dbc63d8272503e80cd2ffd63a2a7
Audio HAL server needs to set SCHED_FIFO scheduling policy
for its threads that communicate with FastMixer threads of
AudioFlinger that use the same scheduler.
Bug: 30222631
Change-Id: I405a69d097a6bfed455e3483365b27c4004e1063
Enabling/disabling sepolicy based on ENABLE_TREBLE is not granular
enough (ref: b/32978887 #4).
Bug: 32978887
Test: compiles, doesn't cause any additional denials on device. Nothing
depends on these things I'm removing.
Change-Id: I10acbde16e5e2093f2c9205ed79cd20caed7f44d
Generate a compile time error if someone unexpectedly tries to
transition into logpersist or logd domain.
Test: compile
Bug: 30566487
Change-Id: Ib55f301f104ad63de5ac513cdc9dc9937e3ba48d
- transition to logpersist from init
- sort some overlapping negative references
- intention is to allow logpersist to be used by vendor
userdebug logging
Test: gTest liblog-unit-tests, logd-unit-tests & logcat-unit-tests
Bug: 30566487
Change-Id: I7806f5a2548cbe0c1f257a0ba2855f2eb69d8e7c
auditallow (added in commit 758e6b3678)
has been in place for about 2 weeks now, and no hits. Remove
execute_no_trans.
The net effect of this change is that priv_apps won't be able to exec()
a file from their home directory, but dlopen() and friends will still
work.
Test: Compiles and boots successfully.
Test: No auditallow messages received via SELinux denial collection.
Change-Id: I60fcdc260d12e1bcc2355ca4dd912de7e6d0a145
init switch from a setcon() based transition to an exec() based
transition in bug 19702273. Fixup stale comment.
Test: comment only change. Policy compiles.
Bug: 19702273
Change-Id: I6e1b4b3680193453adafa8952a7ea343d2977505
Bug: http://b/32905206
Test: Boot sailfish and no new selinux failures observed in logs
Change-Id: Id9a46180074a61f8cf8d176a7b2ebc995a13b9f9
Signed-off-by: Sandeep Patil <sspatil@google.com>
Test: tested with default health HAL on angler running as service.
Bug: b/32754732
Change-Id: Ie0b70d43cb23cd0878e1b7b99b9bebdbd70d17c7
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit ef62fd9159)
- allows binder calls to hwservicemanager
- allows healthd to read system_file for passthrough HAL
Test: Tested healthd with and without a board specific health HAL on
Angler.
Bug: b/32724915
Change-Id: Icf621859f715cb44bce5d8d3b60320ef495d1543
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit 32cacb42b9)
healthd is being split into 'charger' and 'healthd' processes, that
will never run together. 'charger' is to be run only in charge-only
and recovery, while healthd runs with Android.
While they both share much of battery monitoring code, they both now
have reduced scope. E.g. 'charger', doesn't need to use binder anymore
and healthd doesn't need to do charging ui animation. So, amend the
SEPolicy for healthd to reduce it's scope and add a new one for charger.
Test: Tested all modes {recovery, charger-only, android} with new policy
Change-Id: If7f81875c605f7f07da4d23a313f308b9dde9ce8
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit c73d0022ad)
In order for hal clients to use IServiceManager::registerForNotifications,
the hwservicemanager needs to be able to call into client processes.
Test: WIP
Bug: 33383725
Change-Id: I59470e9cd5cbeafda010fedc0b91eeb41280e0a1
Add a compile time assertion that only authorized SELinux domains are
allowed to touch the metadata_block_device. This domain may be wiped at
will, and we want to ensure that we're not inadvertently destroying
other people's data.
Test: policy compiles.
Change-Id: I9854b527c3d83e17f717d6cc8a1c6b50e0e373b6
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
core_property_type is an attribute which was given to all existing
properties known to core SELinux policy. Any property with this label is
readable to all SELinux domains, which is overly broad. The long term
goal is to remove the core_property_type attribute entirely.
Add a neverallow rule prohibiting the introduction of new properties
with the core_property_type attribute. Device specific properties, or
new properties in core SELinux policy, should not have this attribute.
Test: policy compiles
Change-Id: Ie89a9f0d81c8561616001ff8451496ce2278dbb2
There is no reason for vold to have this permission, and a proper
auditallow rule has been used and monitored to ensure that nothing on
android uses this permission.
Bug: 26901147
Test: Phone boots
Change-Id: Id36ed2722348f433fe3d046a3429066338230fec
The new domain wasn't fully tested, and it caused many regressions
on the daily build. Revert back to using "priv_app" domain until we
can fully test and re-land the new domain.
Temporarily add the USB functionfs capabilities to priv_app domain
to keep remainder of MtpService changes working; 33574909 is tracking
removing that from the priv_app domain.
Test: builds, boots, verified UI and downloads
Bug: 33569176, 33568261, 33574909
Change-Id: I1bd0561d52870df0fe488e59ae8307b89978a9cb
Sdcardfs does not use a userspace daemon, so the secontext
is currently the caller's when accessing files. This can be
removed if sdcardfs is modified to change the secontext before
calling into the lower filesystem.
Bug: 32735101
Test: Run any app that falls under isolated_app.
Test: See bug for example
Change-Id: I9433aa0f14ff0d5a518249079e07f57e55b09bcf
Also move necessary priv_app permissions into MediaProvider domain and
remove MediaProvider specific permissions from priv_app.
The new MtpServer permissions fix the following denials:
avc: denied { write } for comm=6D747020666673206F70656E name="ep0" dev="functionfs" ino=12326 scontext=u:r:priv_app:s0:c512,c768 tcontext=u:object_r:functionfs:s0 tclass=file permissive=1
denial from setting property sys.usb.ffs.mtp.ready, context priv_app
Bug: 30976142
Test: Manual, verify permissions are allowed
Change-Id: I4e66c5a8b36be21cdb726b5d00c1ec99c54a4aa4
Need write permissions on the specified sysfs path for reloading
firmware.
Denials:
01-21 23:39:01.650 4669 4669 W android.hardwar: type=1400
audit(0.0:103): avc: denied { write } for name="fwpath" dev="sysfs"
ino=6847 scontext=u:r:hal_wifi:s0
tcontext=u:object_r:sysfs_wlan_fwpath:s0 tclass=file permissive=0
01-21 23:39:01.653 4669 4669 E android.hardware.wifi@1.0-service:
Failed to open wlan fw path param: Permission denied
Bug: 32018162
Test: Denials no longer present in the logs.
Change-Id: I1a468e7c2a2a4360a2b61f04f1940471d52d0dd6
We're going to be using Android framework directly to invoke Wifi HIDL
calls. So, change permissions appropriately.
Bug: 33398154
Test: Verfied that framework is able to make HIDL calls using
go/aog/310610.
Change-Id: I4d0d88961753ad73f3876aec58b26b89486cc02a
This is unused by core policy and by any device policy except for hikey.
Test: device boots
Test: no denials ever collected
Change-Id: I36a6790499e4aeedd808457b43fd72370fa48e53
After a series of recent commits, installd has fully migrated over
to Binder, and all socket-based communication has been removed.
Test: builds, boots, apps install fine, pre-OTA dexopt works
Bug: 13758960, 30944031
Change-Id: Ia67b6260de58240d057c99b1bbd782b44376dfb5
app_domain was split up in commit: 2e00e6373f to
enable compilation by hiding type_transition rules from public policy. These
rules need to be hidden from public policy because they describe how objects are
labeled, of which non-platform should be unaware. Instead of cutting apart the
app_domain macro, which non-platform policy may rely on for implementing new app
types, move all app_domain calls to private policy.
(cherry-pick of commit: 76035ea019)
Bug: 33428593
Test: bullhead and sailfish both boot. sediff shows no policy change.
Change-Id: I4beead8ccc9b6e13c6348da98bb575756f539665
This functionality is being used by priv_apps shipped as part of
Android. Don't drop execute_no_trans as we haven't seen any denials here
yet.
Addresses the following auditallow messages:
avc: granted { execute } for comm="GELServices-0"
path="/data/data/com.google.android.googlequicksearchbox/files/velour/dex_cache/Ji1opKyKASKEOKNQUu1QyWw_1.jar/Ji1opKyKASKEOKNQUu1QyWw_1.dex"
dev="dm-2" ino=1196939 scontext=u:r:priv_app:s0:c512,c768
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
avc: granted { execute } for comm="CTION_IDLE_MODE"
path="/data/data/com.google.android.gms/snet/dalvik-cache/snet.dex"
dev="dm-2" ino=1114262 scontext=u:r:priv_app:s0:c512,c768
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
avc: granted { execute } for comm="lowpool[3]"
path="/data/data/com.google.android.gms/files/libAppDataSearchExt_arm64_v8a.so"
dev="dm-2" ino=1688320 scontext=u:r:priv_app:s0:c512,c768
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
avc: granted { execute } for comm="Binder:9196_2"
path="/data/data/com.google.android.gms/app_dg_cache/1FECE961A655634046D6AB5E18FE6F74212FBEA6/lib/libdC14BB7282EA1.so"
dev="dm-2" ino=1893474 scontext=u:r:priv_app:s0:c512,c768
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
avc: granted { execute } for comm="Binder:13170_1"
path="/data/data/com.google.android.gms/app_fb/f.dex" dev="dm-2"
ino=1810720 scontext=u:r:priv_app:s0:c512,c768
tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file
Test: policy compiles.
Change-Id: I63358697b07c8f620b999e666791f4f385bab776
Make all platform tyeps public to start to prevent build breakage in any devices
that may have device-specific policy using these types. Future changes will
need to be carefully made to ensure we properly limit types for use by
non-platform policy.
Test: Builds
Change-Id: I7349940d5b5a57357bc7c16f66925dee1d030eb6
webview_zygote needs to preload the WebView implementation, which may be
an installed APK, so must be able to read and execute code from inside
the APK.
Also add additional neverallow assertions to strengthen some
restrictions on this domain.
Test: WebView apps work after installing a WebView APK.
Bug: 21643067
Change-Id: I58aedc5e0a25259e2e20c70d4260579a354b6789
In order to support platform changes without simultaneous updates from
non-platform components, the platform and non-platform policies must be
split. In order to provide a guarantee that policy written for
non-platform objects continues to provide the same access, all types
exposed to non-platform policy are versioned by converting them and the
policy using them into attributes.
This change performs that split, the subsequent versioning and also
generates a mapping file to glue the different policy components
together.
Test: Device boots and runs.
Bug: 31369363
Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317
Most of this CL mirrors what we've already done for the "netd" Binder
interface, while sorting a few lists alphabetically.
Migrating installd to Binder will allow us to get rid of one of
the few lingering text-based command protocols, improving system
maintainability and security.
Test: builds, boots
Bug: 13758960, 30944031
Change-Id: I59b89f916fd12e22f9813ace6673be38314c97b7
system/core commit 6a70ded7bfa8914aaa3dc25630ff2713ae893f80 (later
amended by 107e29ac1b1c297a0d4ee35c4978e79f47013e2c indicated that logd
doesn't want it's memory accessible by anyone else. Unfortunately,
setting DUMPABLE isn't sufficient against a root level process such with
ptrace. Only one such process exists, "debuggerd".
Block debuggerd from accessing logd's memory on user builds. Userdebug
and eng builds are unaffected. Add a neverallow rule (compile time
assertion + CTS test) to prevent regressions.
Bug: 32450474
Test: Policy compiles.
Change-Id: Ie90850cd91846a43adaa0871d239f894a0c94d38
Broke the dragon build:
libsepol.report_failure: neverallow on line 304 of system/sepolicy/public/domain.te (or line 8638 of policy.conf) violated by allow kernel device:chr_file { create setattr };
libsepol.check_assertions: 1 neverallow failures occurred
Error while expanding policy
This reverts commit ed0b4eb366.
Change-Id: I5d55ab59ed72ce7c19a10ddbb374f9f3b3fae4fd
By default, files created in /dev are labeled with the "device" label
unless a different label has been assigned. The direct use of this
generic label is discouraged (and in many cases neverallowed) because
rules involving this label tend to be overly broad and permissive.
Today, generically labeled character devices can only be opened, read,
or written to by init and ueventd.
$ sesearch --allow -t device -c chr_file -p open,read,write out/target/product/marlin/root/sepolicy
allow init device:chr_file { setattr read lock getattr write ioctl open append };
allow ueventd device:chr_file { read lock getattr write ioctl open append };
this is enforced by the following SELinux neverallow rule (compile time
assertion + CTS test):
neverallow { domain -init -ueventd } device:chr_file { open read write };
Start auditallowing ueventd access to /dev character device files with the
default SELinux label. This doesn't appear to be used, but let's prove it.
While ueventd is expected to create files in /dev, it has no need to open
most of the files it creates.
Note, however, that because ueventd has mknod + setfscreate permissions,
a malicious or compromised ueventd can always create a device node under
an incorrect label, and gain access that way.
The goal of this change is to prove that no process other than init are
accessing generically labeled files in /dev.
While I'm here, tighten up the compile time assertion for
device:chr_file to include more permissions.
Test: policy compiles + device boots with no granted messages.
Change-Id: Ic98b0ddc631b49b09e58698d9f40738ccedd1fd0
Only init and ueventd have any access to /dev/port, and neither should
have any use for it. As it stands, leaving port in just represents
additional attack surface with no useful functionality, so it should be
removed if possible, not only from Pixel devices, but from all Android
devices.
Test: The phone boots successfully
Bug:33301618
Change-Id: Iedc51590f1ffda02444587d647889ead9bdece3f
In general, apps shouldn't be executing data from their writable data
directories. Allowing this is a security risk and use cases for this are
almost always anti-patterns where saner alternatives are available such
as using one of the standard systems for shipping libraries (extracted
by the package manager or aligned/uncompressed in the apk) or using the
existing package system to handle plugins. It's reasonable for the
untrusted_app domain to have this (not just for backwards compatibility)
for priv_app should be held to a higher standard.
Ideally, untrusted apps would be able to opt-in to disabling this and
then the default could then be switched at a new API level. It could do
more than just hardening apps not requiring it by having documentation
explain the risks and offer alternatives to reduce 'legitimate' use. The
base system could disable it for all of the bundled untrusted apps.
Change-Id: I4efcfaf01c6b6c33c39e98c22a1934e8892e2147
