18ccf9725e
Revert submission 1498525-revert-1499099-revert-1450615-mac-address-restrictions-MNRMVNXRJM-OSETMCLBXY
Reason for revert: b/173384499#comment21
Reverted Changes:
I320d3bcf8:Revert^2 "Enforce RTM_GETLINK restrictions on all ...
I51c83733c:Revert^2 "Return anonymized MAC for apps targeting...
I0e8280c74:Revert "Revert "Updates tests for untrusted app MA...
Ia9f61819f:Revert^2 "Soft-enables new MAC address restriction...
Change-Id: I35a00e187f1b39f6aaa777709fb948f840565a82
the cgroups v2 uid/gid hierarchy will replace cgroup for all sepolicy
rules. For this reason, old rules have to be duplicated to cgroup_v2,
plus some rules must be added to allow the ownership change for cgroup
files created by init and zygote.
Test: booted device, verified correct access from init, system_server
and zygote to the uid/pid cgroup files
Change-Id: I80c2a069b0fb409b442e1160148ddc48e31d6809
f48d1f8e46
The original change was reverted due to InterfaceParamsTest failing.
This test has now been fixed in r.android.com/1498525.
The original change message is below.
This restriction was previously targetSdk gated for apps
with targetSdkVersion>=30.
This change is being posted for app-compat analysis and testing.
Bug: 170188668
Test: build
Change-Id: I320d3bcf8bb64badc39688b19902d532c802dc75
Revert "Updates tests for untrusted app MAC address restrictions"
Revert submission 1450615-mac-address-restrictions
Reason for revert: DroidMonitor: Potential culprit for Bug 173243616 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted
Reverted Changes:
I08c709b2b:Enforce RTM_GETLINK restrictions on all 3p apps
I95d124ae8:Soft-enables new MAC address restrictions.
I5392f8339:Updates tests for untrusted app MAC address restri...
I9d214c5d0:Return anonymized MAC for apps targeting SDK < 30
Change-Id: I987dfc86dfba56a2d2a45075dc19885ca6f0a4ad
Few domains are granted access to this, but they should have access
from any user.
Also add some neverallows to prevent misuse.
Bug: 170622707
Test: presubmits
Change-Id: Iacbe7b0525604f2339f8bf31c105af738bc3cd75
Before, we completely dissallowed any untrusted app to access a service
operated by vendor. However, sometimes this is needed in order to
implement platform APIs. So now, vendor services which aren't explicitly
marked as 'protected_service' (like protected_hwservice in HIDL) are
blocked from being used by apps. This gives everyone a mechanism for
apps to directly access vendor services, when appropriate.
For instance:
VINTF
|
vendor.img/etc | system.img/etc
|
(vendor HAL) <----AIDL---|--> (public lib <-- loaded by app
| or platform
| component)
|
|
Fixes: 163478173
Test: neverallow compiles
Change-Id: Ie2ccbff4691eafdd226e66bd9f1544be1091ae11
This restriction was previously targetSdk gated for apps
with targetSdkVersion>=30.
This change is being posted for app-compat analysis and testing.
Bug: 170188668
Test: build
Change-Id: I08c709b2bb9a67157d0daf921e8ac7717a3bdf6f
It needs to be able to see supported filesystems to handle external
storage correctly.
Bug: 146419093
Test: no denials
Change-Id: Ie1e0313c73c02a73558d07ccb70de02bfe8c231e
This is a domain for the MediaProvider mainline module. The
MediaProvider process is responsible for managing external storage, and
as such should be able to have full read/write access to it. It also
hosts a FUSE filesystem that allows other apps to access said storage in
a safe way. Finally, it needs to call some ioctl's to set project quota
on the lower filesystem correctly.
Bug: 141595441
Test: builds, mediaprovider module gets the correct domain
Change-Id: I0d705148774a1bbb59c927e267a484cb5c44f548
Enforce new requirements on app with targetSdkVersion=30 including:
- No RTM_GETLINK on netlink route sockets.
Remove some of the repetitive descriptions in each untrusted_app_N.te
file, and instead refer to the description in
public/untrusted_app.te.
Bug: 141455849
Test: CtsSelinuxTargetSdkCurrentTestCases
Test: libcore.java.net.NetworkInterfaceTest#testGetNetworkInterfaces
Change-Id: I89553e48db3bc71f229c71fafeee9005703e5c0b
This reverts commit a1aa2210a9.
Reason for revert: Potential culprit for Bug b/148049462 - verifying through Forrest before revert submission
Change-Id: Ibe4fa1dee84defde324deca87d9de24a1cc2911a
Enforce new requirements on app with targetSdkVersion=30 including:
- No bind() on netlink route sockets.
- No RTM_GETLINK on netlink route sockets.
Remove some of the repetitive descriptions in each untrusted_app_N.te
file, and instead refer to the description in
public/untrusted_app.te.
Bug: 141455849
Test: CtsSelinuxTargetSdkCurrentTestCases
Change-Id: Iad4d142c0c13615b4710d378bc1feca4d125b6cc
Only allow apps targetting < Q and ephemeral apps to open /dev/ashmem.
Ephemeral apps are not distinguishable based on target API. So allow
ephemeral_app to open /dev/ashmem for compatibility reasons.
For sake of simplicity, allow all domains /dev/ashmem permissions other
than "open". Reason being that once we can remove "open" access
everywhere, we can remove the device altogether along with other
permission.
Bug: 134434505
Test: boot crosshatch; browse internet, take picture;
no ashmem_device denials
Change-Id: Ie2464c23d799550722580a21b4f6f344983b43ba
Only allow apps targetting < Q and ephemeral apps to open /dev/ashmem.
Ephemeral apps are not distinguishable based on target API. So allow
ephemeral_app to open /dev/ashmem for compatibility reasons.
For sake of simplicity, allow all domains /dev/ashmem permissions other
than "open". Reason being that once we can remove "open" access
everywhere, we can remove the device altogether along with other
permission.
Bug: 134434505
Test: boot crosshatch; browse internet, take picture;
no ashmem_device denials
Change-Id: Ib4dddc47fcafb2697795538cdf055f305fa77799
Before this change, access to HALs from untrusted apps was prohibited
except for the whitelisted ones like the gralloc HAL, the renderscript
HAL, etc. As a result, any HAL that is added by partners can't be
accessed from apps. This sometimes is a big restriction for them when
they want to access their own HALs in the same-process HALs running in
apps. Although this is a vendor-to-vendor communication and thus is not
a Treble violation, that was not allowed because their HALs are not in
the whitelist in AOSP.
This change fixes the problem by doing the access control in the
opposite way; access to HALs are restricted only for the blacklisted
ones.
All the hwservice context that were not in the whitelist are now put
to blacklist.
This change also removes the neverallow rule for the binder access to
the halserverdomain types. This is not needed as the protected
hwservices living in the HAL processes are already not accessible; we
have a neverallow rule for preventing hwservice_manager from finding
those protected hwservices from untrusted apps.
Bug: 139645938
Test: m
Merged-In: I1e63c11143f56217eeec05e2288ae7c91e5fe585
(cherry picked from commit 580375c923)
Change-Id: I4e611091a315ca90e3c181f77dd6a5f61d3a6468
The only distinction that matters for security is if a service is
served by vendor or not AND which process is allowed to talk to which.
coredomain is allowed to talk to vintf_service OR vendor_service, it's
just that for a non-@VintfStability service user-defined APIs (as
opposed to pingBinder/dump) are restricted.
Bug: 136027762
Test: N/A
Change-Id: If3b047d65ed65e9ee7f9dc69a21b7e23813a7789
This reverts commit 6b2eaade82.
Reason for revert: reland original CL
Separate runtime infrastructure now makes sure that only Stable AIDL
interfaces are used system<->vendor.
Bug: 136027762
Change-Id: Id5ba44c36a724e2721617de721f7cffbd3b1d7b6
Test: boot device, use /dev/binder from vendor
Separate runtime infrastructure now makes sure that only Stable AIDL
interfaces are used system<->vendor.
Bug: 136027762
Test: boot device, use /dev/binder from vendor
Change-Id: Icdf207c5d5a4ef769c0ca6582dc58306f65be67e
This change is part of enabling upcoming platform changes that are
described in the bug linked below.
Bug: 135341433
Test: m
Change-Id: I6ef499b0d5aa403f8eb6699649a201d8cc004bc5
Media component update service is removed, so selinux
permissions for it are no longer needed.
Bug: 123250010
Test: boot, play video
Change-Id: I0fec6839f5caf53d16399cb72dcdd6df327efc95
There were three separate neverallows here. Simplifying it to one
with only a small number of exceptions.
Bug: 131177459
Bug: 37226359
Test: m sepolicy (checks neverallows)
Change-Id: I93045c9f698f28675c634643a827a1cd513f215e
"This symlink was suppose to have been removed in the Gingerbread
time frame, but lives on."
https://android.googlesource.com/platform/system/core/+/d2f0a2c%5E!/
Apps targeting R+ must NOT use that symlink.
For older apps we allow core init.rc to create
/mnt/sdcard -> /storage/self/primary symlink.
Bug: 129497117
Test: boot device, /mnt/sdcard still around.
Change-Id: I6ecd1928c0f598792d9badbf6616e3acc0450b0d
