Since we are now creating an AOSP HAL for uwb. Rename Pixel specific
internal UWB HAL from Android S to hal_uwb_vendor to avoid conflicts
with the AOSP HAL sepolicy rules that are going to be added in
Android T.
Android S Architecture:
|Apps | AOSP API | Vendor Service | Vendor HAL Interface | Vendor HAL
Implementation | Vendor driver/firmware
Android T Architecture:
|Apps | AOSP API | AOSP Service | AOSP HAL Interface | Vendor HAL
Implementation | Vendor driver/firmware
Ignore-AOSP-First: Dependent changes in internal-only projects.
Bug: 195308730
Test: Compiles
Change-Id: I7bf4794232604372134ea299c8e2a6ba14a801d3
Merged-In: I7bf4794232604372134ea299c8e2a6ba14a801d3
(cherry picked from commit 40465250e4)
(cherry picked from commit 27ab309fad)
Addressing b/194450129 requires configuring the I/O scheduler and the
queue depth of loop devices. Doing this in a generic way requires
iterating over the block devices under /sys/class/block and also to
examine the properties of the boot device (/dev/sda). Hence this patch
that allows 'init' and 'apexd' to read the properties of all block
devices. The patch that configures the queue depth is available at
https://android-review.googlesource.com/c/platform/system/core/+/1783847.
Test: Built Android images, installed these on an Android device and verified that modified init and apexd processes do not trigger any SELinux complaints.
Change-Id: Icb62449fe0d21b3790198768a2bb8e808c7b968e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
We ended up with 4 labels for specific APEX files that were all
identical; I've replaced them with a single one
(apex_system_server_data_file).
Additionally I created an attribute to be applied to a "standard" APEX
module data file type that establishes the basics (it can be managed
by vold_prepare_subdirs and apexd), to make it easier to add new such
types - which I'm about to do.
Fix: 189415223
Test: Presubmits
Change-Id: I4406f6680aa8aa0e38afddb2f3ba75f8bfbb8c3c
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
Bug: 187386527
Test: Boot and confirm HAL is up
Signed-off-by: Michael Ayoubi <mayoubi@google.com>
Change-Id: Ia866a9a72b6f2ea5b31de25baefd13c2fd0b9c22
This reverts commit e95e0ec0a5.
Now that b/186727553 is fixed, it should be safe to revert this revert.
Test: build
Bug: 184381659
Change-Id: Ibea3882296db880f5cafe4f9efa36d79a183c8a1
Revert submission 1668411
Reason for revert: Suspect for b/186173384
Reverted Changes:
Iaa4fce9f0:Check that tracefs files are labelled as tracefs_t...
I743a81489:Exclude vendor_modprobe from debugfs neverallow re...
I63a22402c:Add neverallows for debugfs access
I289f2d256:Add a neverallow for debugfs mounting
Change-Id: I9b7d43ac7e2ead2d175b265e97c749570c95e075
Android R launching devices and newer must not ship with debugfs
mounted. For Android S launching devices and newer, debugfs must only be
mounted in userdebug/eng builds by init(for boot time initializations)
and dumpstate(for grabbing debug information from debugfs using the
dumpstate HAL).
This patch adds neverallow statements to prevent othe processes
being provided access to debugfs when the flag PRODUCT_SET_DEBUGFS_RESTRICTIONS
is set to true.
Test: make with/without PRODUCT_SET_DEBUGFS_RESTRICTIONS
Bug: 184381659
Change-Id: I63a22402cf6b1f57af7ace50000acff3f06a49be
Split gsi_metadata_file into gsi_metadata_file plus
gsi_public_metadata_file, and add gsi_metadata_file_type attribute.
Files that are okay to be publicly readable are labeled with
gsi_public_metadata_file. Right now only files needed to infer the
device fstab belong to this label.
The difference between gsi_metadata_file and gsi_public_metadata_file is
that gsi_public_metadata_file has relaxed neverallow rules, so processes
who wish to read the fstab can add the respective allow rules to their
policy files.
Allow gsid to restorecon on gsi_metadata_file to fix the file context of
gsi_public_metadata_file.
Bug: 181110285
Test: Build pass
Test: Issue a DSU installation then verify no DSU related denials and
files under /metadata/gsi/ are labeled correctly.
Change-Id: I54a5fe734dd345e28fd8c0874d5fceaf80ab8c11
One of the advantages of the DMA-BUF heaps framework over
ION is that each heap is a separate char device and hence
it is possible to create separate sepolicy permissions to restrict
access to each heap.
In the case of ION, allocation in every heap had to be done through
/dev/ion which meant that there was no away to restrict allocations in
a specific heap.
This patch intends to restrict coredomain access to only approved
categories of vendor heaps. Currently, the only identified category
as per partner feedback is the system-secure heap which is defined
as a heap that allocates from protected memory.
Test: Build, video playback works on CF with ION disabled and
without sepolicy denials
Bug: 175697666
Change-Id: I923d2931c631d05d569e97f6e49145ef71324f3b
16d61d0383
Bug: 175345910
Bug: 171429297
Exempt-From-Owner-Approval: re-landing topic with no changes in this CL.
Change-Id: I1352c6b46b007dba3448b3c9cbdf454d7862a176
We need to be able to access app data files from core domains such as
installd even for vendor apps. Those file types should not be
core_data_file_type, so we explicitly exempty app_data_file_type as
well as core_data_file_type from the relevant neverallows.
To prevent misuse of the attribute, add a test to check it is not
applied to anything in file_contexts. Exempt the existing violators in
system policy for now.
Test: Builds
Test: Adding a type with just "file_type, data_file_type, app_data_file_type" works
Test: New test successfully catches violators.
Bug: 171795911
Change-Id: I07bf3ec3db615f8b7a33d8235da5e6d8e2508975
This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
This mostly reverts the revert in commit
b01e1d97bf, restoring commit
27e0c740f1. Changes to check_seapp to
enforce use of app_data_file_type is omitted, to be included in a
following CL.
Test: Presubmits
Bug: 171795911
Change-Id: I02b31e7b3d5634c94763387284b5a154fe5b71b4
This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
Also extend check_seapp to check that all types specified in
seapp_contexts files have the attribute, to ensure that the neverallow
rules apply to them. As a small bonus, also verify that domain and
type values are actually types not attributes.
Test: Presubmits
Test: Manual: specify an invalid type, build breaks.
Bug: 171795911
Change-Id: Iab6018af449dab3b407824e635dc62e3d81e07c9
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
Certain classes of 3rd party apps aren't untrusted_app_domain, but
some comments surrounding this are either outdated or wrong.
Bug: 168753404
Test: N/A
Change-Id: I019c16e26a3778536132f22c37fbea5ae7781af4
It's release blocking if devices specify it. Since none are used
in-tree anymore, no reason to every use this again.
Bug: 131617943
Test: grepping source/build (which validates this isn't used)
Change-Id: I6f98ab9baed93e11403a10f3a0497c855d3a8695
We add a new back end for SELinux based keystore2_key namespaces.
This patch adds the rump policy and build system infrastructure
for installing keystore2_key context files on the target devices.
Bug: 158500146
Bug: 159466840
Test: None
Change-Id: I423c9e68ad259926e4a315d052dfda97fa502106
Merged-In: I423c9e68ad259926e4a315d052dfda97fa502106
This is unused currently & there are no concrete plans to use it
in the future.
Bug: 130080335
Test: Device boots up & connects to networks.
Test: Will send for regression tests
Change-Id: I785389bc2c934c8792c8f631362d6aa0298007af
Merged-In: I785389bc2c934c8792c8f631362d6aa0298007af
(cherry picked from commit 56dfc06397)
When an OTA is downloaded, the RecoverySystem can be triggered to store
the user's lock screen knowledge factor in a secure way using the
IRebootEscrow HAL. This will allow the credential encrypted (CE)
storage, keymaster credentials, and possibly others to be unlocked when
the device reboots after an OTA.
Bug: 63928581
Test: make
Test: boot emulator with default implementation
Test: boot Pixel 4 with default implementation
Change-Id: I1f02e7a502478715fd642049da01eb0c01d112f6
This introduces some attributes that can be used to restrict access to
exported properties so that one can easily check from which the
properties can be accessed, and that OEMs can extend their own exported
properties.
Bug: 71814576
Bug: 131162102
Test: boot aosp_cf_x86_phone-userdebug
Test: logcat | grep "avc: "
Change-Id: I6f988ec1cb94fa64563ca6cb91b7702da5d604e3
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
These attributes are intended to be used w/ services using the system
copy of libbinder (for vendor, this is libbinder_ndk).
Switching vndservicemanager users using the libbinder copy of vendor to
be able to use the system copy of libbinder for registration is an open
problem.
Bug: 136027762
Test: N/A
Change-Id: I1d70380edcb39ca8ef2cb98c25617701b67ba7e1
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
