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
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: I4731a8ec846c5cb84ec4b680d51938494e8ddd75
Remove blanket coredomain access to same_process_hal_file in favor of
granular access. This change takes into account audits from go/sedenials
(our internal dogfood program)
Bug: 37211678
Test: m selinux_policy
Change-Id: I5634fb65c72d13007e40c131a600585a05b8c4b5
What changed:
- Removed cgroup access from untrusted and priv apps.
- Settings app writes to /dev/stune/foreground/tasks, so system_app domain
retains access to cgroup.
- libcutils exports API to /dev/{cpuset, stune}/*. This API seems to be used
abundantly in native code. So added a blanket allow rule for (coredomain - apps)
to access cgroups.
- For now, only audit cgroup access from vendor domains. Ultimately, we want to
either constrain vendor access to individual domains or, even better, remove
vendor access and have platform manage cgroups exclusively.
Changes from original aosp/692189 which was reverted:
- There seem to be spurious denials from vendor-specific apps. So added
back access from { appdomain -all_untrusted_apps -priv_app } to cgroup.
Audit this access with intent to write explicit per-domain rules for it.
Bug: 110043362
Test: adb shell setprop ro.config.per_app_memcg true, device correctly populates
/dev/memcg on a per app basis on a device that supports that.
Test: aosp_sailfish, wahoo boot without cgroup denials
This reverts commit cacea25ed0.
Change-Id: I05ab404f348a864e8409d811346c8a0bf49bc47a
This reverts commit 9899568f6c.
Reason for revert: Reports of high numbers of SELinux denials
showing up on the SELinux dashboard.
Bug: 110043362
Change-Id: Id8fc260c47ffd269ac2f15ff7dab668c959e3ab0
What changed:
- Removed cgroup access from untrusted and priv apps.
- Settings app writes to /dev/stune/foreground/tasks, so system_app domain
retains access to cgroup.
- libcutils exports API to /dev/{cpuset, stune}/*. This API seems to be used
abundantly in native code. So added a blanket allow rule for (coredomain - apps)
to access cgroups.
- For now, only audit cgroup access from vendor domains. Ultimately, we want to
either constrain vendor access to individual domains or, even better, remove
vendor access and have platform manage cgroups exclusively.
Bug: 110043362
Test: adb shell setprop ro.config.per_app_memcg true, device correctly populates
/dev/memcg on a per app basis on a device that supports that.
Test: aosp_sailfish, wahoo boot without cgroup denials
Change-Id: I9e441b26792f1edb1663c660bcff422ec7a6332b
Remove these files from proc_net_type. Domains that need access must
have permission explicitly granted. Neverallow app access except the
shell domain.
Bug: 114475727
Test: atest CtsLibcoreOjTestCases
Test: netstat, lsof
Test: adb bugreport
Change-Id: I2304e3e98c0d637af78a361569466aa2fbe79fa0
DropboxManager may pass FDs to any app with the READ_LOGS
permission which is available to all apps as a development
permission.
Test: atest CtsIncidentHostTestCases
Fixes: 111856304
Change-Id: I329e3125dab83de948b860061df9d232e31cb23e
llkd needs the ptrace capabilities and dac override to monitor for
live lock conditions on the stack dumps.
Test: compile
Bug: 33808187
Change-Id: Ibc1e4cc10395fa9685c4ef0ca214daf212a5e126
Linux kernel 4.14+ SELinux starts explicit map
permission check for file mmap operations. For backards
compat, add mmap in more places where we explicitly
list out individual file permissions.
Test: policy compiles
Change-Id: Idc4ca53769f2e7aa12ed93ab27191ed92da37a3e
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.
This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:
-user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
+user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
For now, this newly introduced label has no usage, so this change
is essentially a no-op.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
The Android security model guarantees the confidentiality and integrity
of application data and execution state. Ptrace bypasses those
confidentiality guarantees. Disallow ptrace access from system components
to apps. Crash_dump is excluded, as it needs ptrace access to
produce stack traces.
Bug: 111317528
Test: code compiles
Change-Id: I883df49d3e9bca62952c3b33d1c691786dd7df4d
Cut down on logspam during kernel_net_tests
Test: /data/nativetest64/kernel_net_tests/kernel_net_tests
Change-Id: Id19f50caebc09711f80b7d5f9d87be103898dd9a
Before, it was possible to access a hwservice without declaring
that you were a client.
This introduces the following macro:
hal_attribute_hwservice_client(hal_foo, hal_foo_hwservice)
which makes sure the above implication holds using a neverallow rule.
Bug: 80319537
Test: boot + sanity
Change-Id: Iededae68f14f0f3bd412c1205aa3b650a54d55c6
