Any FUSE filesystem will receive the 'fuse' type when mounted. It is
possible to change this behaviour by specifying the "context=" or
"fscontext=" option in mount().
Because 'fuse' has historically been used only for the emulated storage,
it also received the 'sdcard_type' attribute. Replace the 'sdcard_type'
attribute from 'fuse' with the new 'fusefs_type'. This attribute can be
attached on derived types (such as app_fusefs).
This change:
- Remove the neverallow restriction on this new type. This means any
custom FUSE implementation can be mounted/unmounted (if the correct
allow rule is added). See domain.te.
- Change the attribute of 'fuse' from 'sdcard_type' to 'fusefs_type'.
See file.te.
- Modify all references to 'sdcard_type' to explicitly include 'fuse'
for compatibility reason.
Bug: 177481425
Bug: 190804537
Test: Build and boot aosp_cf_x86_64_phone-userdebug
Change-Id: Id4e410a049f72647accd4c3cf43eaa55e94c318f
These properties allow to vendors to provide their
own camera2 extensions service. The properties
must be accesible to any android app that wishes
to use camera2 extensions.
Change-Id: I94c7ac336b3103355124830320787472f0d2a8b6
The primary goal is to have an ashmem region shared between the main app
process in Chrome (=Browser Process) and the app zygote. It can only be
passed from the App Zygote, since there is no communication in the other
direction. Passing of the file descriptor should happen by:
(A) inheriting via fork(2)
(B) using binder IPC
Currently ashmem FDs are sufficiently allowed to be mmap(2)-ed in all
Chrome processes. The mode of mapping (read-only, read-write etc.) is
controlled by the settings of the region itself, not by sepolicy.
This change additionally allows an FD created in the app zygote to be
passed to the 'untrusted_app' domain.
Note: This change allows *any* FD, not just an ashmem one to be passed.
This is on purpose: in the future we will likely want to return to the
memfd story. Other usecases (pipes, sockets) might appear.
The app zygote preload takes the responsibility not to share
capabilities in the form of FDs unintentionally with other app
processes.
Historical note: we tried to enable this for memfd (using additional
rules), but it required a 'write' permission when sending an FD. Reasons
for that are still puzzling, and there seems to be no easy workaround
for it. Decision: use ashmem.
Bug: 184808875
Test: Manual: Build and install Chrome (trichrome_chrome_google_bundle)
from [1]. Make sure FileDescriptorAllowlist allows the FD, like
[2]. Reach a NewTabPage, click on a suggested page, observe no
errors related to binder transactions and selinux violations.
[1] A change in Chrome to create an ashmem region during app zygote
preload and pass it to the browser process:
https://crrev.com/c/2752872/29
[2] Allowlist change in review:
https://android-review.googlesource.com/c/platform/frameworks/base/+/1739393
(Alternatively: Remove gOpenFdTable checks in ForkCommon() in
com_android_internal_os_Zygote.cpp)
Change-Id: Ide085f472c8fb6ae76ab0b094319d6924552fc02
Apps should be able to share their private files over binder,
including system_app.
Bug: 188869889
Test: go to setting ==> system ==> multi-users ==> tap icon to change
profile photo with camera
Change-Id: I3dc732f727b9b697c9a73f6089392690109ae035
Add "ro.camerax.extensions.enabled" vendor-specific property.
Allow public apps to read this property.
Bug: 171572972
Test: Camera CTS
Change-Id: Id5fadedff6baaaebe5306100c2a054e537aa61ed
The fd shared here is the fast message queue descriptor of the Tuner
Filter MQ or DVR MQ, sent from the Tuner HAL HIDL interface to Tuner Service.
Tuner service would convert the hidl mq descriptor into an aidl one then
passed to the Tuner JNI. Tuner JNI would read/write data into fmq
through the shared fd when the third-party app calls corresponding APIs.
The fd won't be exposed through SDK APIs.
The same fd won't be shared among apps. Each app only has access to
their own Tuner java instance through Tuner SDK, and read/write their
own Filter/Dvr.
Test: atest TunerDvrTest#testDvrPlayback
Bug: 159067322
Bug: 174500129
Bug: 171378420
Bug: 158868205
Change-Id: I34c113a092673f8ea9bcb7428b5562101c4d35ec
And allow access from system apps to vendor libs public only for system.
These files should be marked individually by OEMs. Maintainance
ownership for these libraries is also OEM's responsability.
Similar with vendor_public_libs_file type, this allows for an explicit
labeling of OEM system apps that can access libs from vendor.
Bug: 172526961
Test: build-only change, policy builds
Change-Id: I7d4c8232e0b52e73f373d3347170c87ab2dcce52
odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
user_profile_data_file is mlstrustedobject. And it needs to be,
because we want untrusted apps to be able to write to their profile
files, but they do not have levels.
But now we want to apply levels in the parent directories that have
the same label, and we want them to work so they need to not be
MLS-exempt. To resolve that we introduce a new label,
user_profile_root_file, which is applied to those directories (but no
files). We grant mostly the same access to the new label as
directories with the existing label.
Apart from appdomain, almost every domain which accesses
user_profile_data_file, and now user_profile_root_file, is already
mlstrustedsubject and so can't be affected by this change. The
exception is postinstall_dexopt which we now make mlstrustedobject.
Bug: 141677108
Bug: 175311045
Test: Manual: flash with wipe
Test: Manual: flash on top of older version
Test: Manual: install & uninstall apps
Test: Manual: create & remove user
Test: Presubmits.
Change-Id: I4e0def3d513b129d6c292f7edb076db341b4a2b3
The list permission protects the ability to list arbitrary namespaces.
This is not a namespace specific permission but a Keystore specific
permission. Listing the entries of a given namsepace is covered by the
get_info permission already.
Ignore-AOSP-First: This needs to land in googleplex first to updated
prebuilt vendor images. Otherwise it breaks
aosp-with-phone builds.
Test: N/A
Change-Id: If6e79fd863a79acf8d8ab10c6362a4eeaa88a5b8
Bug: 158500146
Bug: 159466840
Test: keystore2_test tests part of this policy
Change-Id: Id3dcb2ba4423d93170b9ba7ecf8aed0580ce83bc
Merged-In: Id3dcb2ba4423d93170b9ba7ecf8aed0580ce83bc
We have various apps which inherently work across all users,
configured in seapp_contexts with levelFrom=None (usually implicitly).
This change marks those apps, where they have private data files, as
mlstrustedsubject, to allow us to increase restrictions on cross-user
access without breaking them.
Currently these apps are granted full access to [priv_]app__data_file
via TE rules, but are blocked from calling open (etc) by mls rules
(they don't have a matching level).
This CL changes things round so they are granted access by mls, but
blocked from calling open by TE rules; the overall effect is thus the
same - they do not have access.
A neverallow rule is added to ensure this remains true.
Note that there are various vendor apps which are appdomain,
levelFrom=None; they will also need modified policy.
Test: builds, boots, no new denials.
Bug: 141677108
Change-Id: Ic14f24ec6e8cbfda7a775adf0c350b406d3a197e
This property allows us to disable sdcardfs if it is present. The old
property ended up getting repurposed, so a new one was needed.
Mediaprovider will also need to access this to determine what actions it
needs to take.
Test: builds
Bug: 155222498
Change-Id: I66ac106613cbb374f54659601e4ba3f61eaecd2f
Previously we have allowed many kinds of app processes to access
gpuservice. However, upon sharing files through bluetooth, bluetooth
process starts an activity to handle this task. At the meanwhile, any
processes with an activity launched shall access gpuservice for stats
purpose. This change amends the rules so that we don't miss anything.
Bug: 153472854
Test: use bluetooth to share a photo and check logcat
Change-Id: I3d620b703d3afe92ac1f61cfb2a2f343352ddd4d
This is needed for the following denial:
type=1400 audit(0.0:124): avc: denied { map } for
comm=54696D652D6C696D69746564207465 path="/mnt/appfuse/10182_2/2"
dev="fuse" ino=2 scontext=u:r:untrusted_app:s0:c182,c256,c512,c768
tcontext=u:object_r:app_fuse_file:s0 tclass=file permissive=0
Bug: 150801745
Test: atest CtsBlobStoreTestCases:com.android.cts.blob.BlobStoreManagerTest#testOpenBlob -- --abi x86
Merged-In: Ib7ca64e11b24f8835874698df15a9a0fdce67454
Change-Id: I4dc4ce91da3513a2d1f08ada401741f6d5a090c3
This fixes a bug introduced in aosp/1143430 where the permission
should have been included for the newly introduced
ashmem_libcutils_device type.
Test: Build
Bug: 150193534
Change-Id: I5b1ed8d9548f9dab4ad9373f98e21614c07c3d38
The credstore service is a system service which backs the
android.security.identity.* Framework APIs. It essentially calls into
the Identity Credential HAL while providing persistent storage for
credentials.
Bug: 111446262
Test: atest android.security.identity.cts
Test: VtsHalIdentityTargetTest
Test: android.hardware.identity-support-lib-test
Change-Id: I5cd9a6ae810e764326355c0842e88c490f214c60
This reverts commit d5a0edd75e.
Reason for revert: CTS failure
There are apps that relies on SELinux regulations to constrain their access. We'll need to analyze them before introducing the sepolicy.
Bug: 147695658
Change-Id: Ic57fcb90371b50a978ab7b2e0d20c4cb3d2da7f6
Test: cts-tradefed run cts -m CtsPermissionTestCases
The original idea was to compartmentalize services for apps to access.
ex. an app that manage display brightness should not have access to
audio service.
However, identifying all services is hard and we often end up granting
app_api_service in practice to avoid unexpected crashes.
Bug: 147198856
Test: Remove device app_api_service related sepolicy and related process
remain functional
Change-Id: I3aafcf1a91847a97c86f1d7992653b806a713bd4
This reverts commit 3aa1c1725e.
Reason for revert: Wifi services no longer plan to be a separate
APK/process for mainline. Will instead become a jar loaded from Apex.
Bug: 144722612
Test: Device boots up & connects to wifi networks
Change-Id: Ifa33dae971dccfd5d14991727e2f27d2398fdc74
This reverts commit 1086c7d71d.
Reason for revert: Wifi services no longer plan to be a separate
APK/process for mainline. Will instead become a jar loaded from Apex.
Bug: 144722612
Test: Device boots up & connects to wifi networks
Change-Id: I69ccc6afbe15db88f516cdc64e13d8cfdb0c743c
NetworkStack will need to use netlink_tcpdiag_socket to get tcp
info. In order to support updatability for NetworkStack as it's
a mainline module, get the information from kernel directly to
reduce the dependecy with framework.
Test: Build and test if NetworkStack can get the tcp_info without
SEPolicy exception
Bug: 136162280
Change-Id: I8f584f27d5ece5e97090fb5fafe8c70c5cbbe123
The wifi stack APK will run inside the network_stack process. So, move
the sepolicy rules for wifi stack inside the network stack rules.
Bug: 135691051
Test: Manual tests
- manual connect to wifi networks
- Remove networks
Test: Will send for ACTS wifi regression testing
Change-Id: I9d5da80852f22fa1d12b2dbbc76b9e06c1275310
(cherry-picked from b83abf7af3df64e0d3c1b22548f2344b55aece28)
Move wifi services out of system_server into a separate APK/process.
Changes:
a) Created sepolicy for the new wifi apk.
b) The new APK will run with network_stack uid (eventually will be moved
to the same process).
Used 'audit2allow' tool to gather list of permissions required.
Note: The existing wifi related permissions in system_server is left
behind to allow the module to be loaded into system_server or
network_stack process depending on device configuration.
Bug: 113174748
Test: Device boots up and able to make wifi connection.
Test: Tested hotspot functionality.
Test: Ran WifiManagerTest & WifiSoftApTest ACTS tests locally.
Test: Will send for wifi regression tests.
Change-Id: Id19643a235bf0c28238f2729926b893ac2025b97
(cherry-picked from c7aa90091e6bec70a31a643cc4519a9a86fb0b38)
The bootstrap bionic (/system/lib/bootstrap/*) are only to the early
processes that are executed before the bionic libraries become available
via the runtime APEX. Allowing them to other processes is not needed and
sometimes causes a problem like b/123183824.
Bug: 123183824
Test: device boots to the UI
Test: atest CtsJniTestCases:android.jni.cts.JniStaticTest#test_linker_namespaces
Change-Id: Id7bba2e8ed1c9faf6aa85dbbdd89add04826b160
This change allows those daemons of the audio and Bluetooth which
include HALs to access the bluetooth_audio_hal_prop. This property is
used to force disable the new BluetoothAudio HAL.
- persist.bluetooth.bluetooth_audio_hal.disabled
Bug: 128825244
Test: audio HAL can access the property
Change-Id: I87a8ba57cfbcd7d3e4548aa96bc915d0cc6b2b74
all_untrusted_apps apart from untrusted_app_{25, 27} and mediaprovider
are now expected to go to ashmemd for /dev/ashmem fds.
Give coredomain access to ashmemd, because ashmemd is the default way
for coredomain to get a /dev/ashmem fd.
Bug: 113362644
Test: device boots, ashmemd running
Test: Chrome app works
Test: "lsof /system/lib64/libashmemd_client.so" shows
libashmemd_client.so being loaded into apps.
Change-Id: I279448c3104c5d08a1fefe31730488924ce1b37a
Move all app tmpfs types to appdomain_tmpfs. These are still protected
by mls categories and DAC. TODO clean up other app tmpfs types in a
separate change.
Treble-ize tmpfs passing between graphics composer HAL and
surfaceflinger.
Bug: 122854450
Test: boot Blueline with memfd enabled.
Change-Id: Ib98aaba062f10972af6ae80fb85b7a0f60a32eee
Untrustworthy symlinks dereferenced by priv-apps could cause those apps
to access files they weren't intending to access. Trusted components
such as priv-apps should never trust untrustworthy symlinks from
untrusted apps.
Modify the rules and add a neverallow assertion to prevent regressions.
Bug: 123350324
Test: device boots and no obvious problems.
Change-Id: I8c4a5c9c8571fd29b2844b20b4fd1126db4128c0
The networking stack app hosts services that used to be in the system
server (IpClient, NetworkMonitor for now), but in a different process to
be packaged as a mainline module.
Test: booted, verified networking stack working when in app
Change-Id: I300a556f51b35c17378af961cea1ec937444e597
When daemonizing perfetto, SIGINT should be sent to ensure clean
shutdown.
Denial:
12-06 11:12:16.566 3099 3099 I sh : type=1400 audit(0.0:462): avc: denied { signal } for scontext=u:r:shell:s0 tcontext=u:r:perfetto:s0 tclass=process permissive=1
Test: m
Test: flash walleye
Test: SIGINT perfetto from shell
Change-Id: I8d34b447ea90c315faf88f020f1dfc49e4abbcce
Move rules / neverallow assertions from public to private policy. This
change, by itself, is a no-op, but will make future patches easier to
read. The only downside of this change is that it will make git blame
less effective.
Motivation: When rules are placed into the public directory, they cannot
reference a private type. A future change will modify these rules to
reference a private type.
Test: compiles
Bug: 112357170
Change-Id: I56003409b3a23370ddab31ec01d69ff45c80d7e5
Remove the permission to execute dex2oat from apps targetSdkVersion>28.
This has been historically used by ART to compile secondary dex files
but that functionality has been removed in Q and the permission is
therefore not needed.
Some legacy apps do invoke dex2oat directly. Hence allow (with audit) for
targetSdkVersion<= 28.
Test: atest CtsSelinuxTargetSdk25TestCases
Test: atest CtsSelinuxTargetSdk27TestCases
Test: atest CtsSelinuxTargetSdkCurrentTestCases
Bug: 117606664
Change-Id: I2ea9cd56861fcf280cab388a251aa53e618160e5
Commit 619c1ef2ac ("tun_device: enforce
ioctl restrictions") completely removed the ability of untrusted apps to
issue ioctl calls to tun_device. It turns out that this was too
aggressive. Wireshark apparently uses the TUNGETIFF ioctl.
Fixes the following denial:
audit(0.0:384744): avc: denied { ioctl } for comm=4173796E635461736B202332 path="/dev/tun" dev="tmpfs" ino=19560 ioctlcmd=54d2 scontext=u:r:untrusted_app:s0:c51,c257,c512,c768 tcontext=u:object_r:tun_device:s0 tclass=chr_file permissive=1 app=com.wireguard.android
Test: policy compiles.
Change-Id: I71bb494036ea692781c00af37580748ab39d1332
We are moving AppFuse mount from system_server's mount namespace to
vold. Hence, we could reduce the SELinux permissions given to
system_server, in the expense of adding allow rules to vold and
letting appdomain have access to vold's fd.
Bug: 110379912
Test: testOpenProxyFileDescriptor passes (after vold and
system_server code changes)
Change-Id: I827a108bd118090542354360a8c90b295e6a0fef
Require all SELinux domains which have permission to perform ioctls on
/dev/tun explicitly specify what ioctls they perform. Only allow the
safe defaults FIOCLEX and FIONCLEX, which are alternate, uncommon ways
to set and unset the O_CLOEXEC flag.
Remove app's ability to issue *any* ioctls on /dev/tun, period. Add
neverallow assertions (compile time assertion + CTS test) to prevent
regressions.
Limit system_server's ability to perform ioctls on /dev/tun to FIOCLEX,
FIONCLEX, TUNGETIFF, and TUNSETIFF. Testing and source code examination
shows that only TUNGETIFF and TUNSETIFF are used by system_server.
The goal of this change is to put SELinux ioctl controls in place for
/dev/tun, so we don't have to maintain the custom kernel patch at
11cee2be0c%5E%21
Delete the neverallow assertion in isolated_app.te. This is already
covered by the assertion present in app_neverallows.te.
Test: cts-tradefed run cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideVpnTests
Test: cts-tradefed run cts -m CtsHostsideNetworkTests
Test: cts-tradefed run cts -m CtsNetTestCases
Bug: 111560739
Bug: 111560570
Change-Id: Ibe1c3a9e880db0bee438535554abdbc6d84eec45
