tests/sepolicy_tests.py has been checking whether the property owner
attributes are mutually exclusive. This is because current policy
language can't express the following snippet:
neverallow domain {
system_property_type && vendor_property_type
}:file no_rw_file_perms;
neverallow domain {
system_property_type && vendor_property_type
}:property_service set;
This uses technical_debt.cil to workaround this.
Bug: 171437654
Test: Try to compile a type having both system_property_type and
vendor_property_type
Change-Id: Ic65f2d00aa0f2fb7f5d78331b0a26e733fcd128e
set_prop(hal_wifi, wifi_hal_prop) violates a neverallow rule
on PRODUCT_SHIPPING_API_LEVEL=28 b/173611344#comment20
Bug: 173611344
Test: m
Change-Id: I56ff953e196777ffdc7a8ca92bcf788e3431aaac
Define access rights to new per-API level task profiles and cgroup
description files under /etc/task_profiles/.
Bug: 172066799
Test: boot with per-API task profiles
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I04c9929fdffe33a9fc82d431a53f47630f9dcfc3
One day we won't need this mechanism any more & can remove all traces
of it.
Bug: 141677108
Test: builds
Change-Id: I95525a163ab4f19d8ca411c02a3c06498c6777ef
The new geotz module has files that need to be readable by the system
process.
Bug: 172546738
Test: build / boot
Change-Id: I4b9867fa1f738b0fabdf5b72e9e73282f1bd9cbc
Restrict access to controlling snapuserd via ctl properties. Allow
update_engine to control snapuserd, and connect/write to its socket.
update_engine needs this access so it can create the appropriate dm-user
device (which sends queries to snapuserd), which is then used to build
the update snapshot.
This also fixes a bug where /dev/dm-user was not properly labelled. As a
result, snapuserd and update_engine have been granted r_dir_perms to
dm_user_device.
Bug: 168554689
Test: full ota with VABC enabled
Change-Id: I1f65ba9f16a83fe3e8ed41a594421939a256aec0
VTS tests require access to cgroups.json system and vendor files. Enable
read access to these files from shell.
Bug: 172868075
Test: vts_processgroup_validate_test
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I16ad13729e10c4e033499351761b163cad7cef34
These are read by some apps, but don't have any corresponding property
contexts. This adds a new context as we're going to remove default_prop
access.
Bug: 173360450
Test: no sepolicy denials
Change-Id: I9be28d8e641eb6380d080150bee785a3cc304ef4
We no longer allow apps with mlstrustedsubject access to app_data_file
or privapp_data_file. For compatibility we grant access to all apps on
vendor images for SDK <= 30, whether mlstrustedsubject or not. (The
ones that are not already have access, but that is harmless.)
Additionally we have started adding categories to system_data_file
etc. We treat these older vendor apps as trusted for those types only.
The result is that apps on older vendor images still have all the
access they used to but no new access.
We add a neverallow to prevent the compatibility attribute being
abused.
Test: builds
Change-Id: I10a885b6a122292f1163961b4a3cf3ddcf6230ad
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
We want to tweak some device params at runtime via shell (alleviates the
need to recompile HAL for changing device configuration). This will help
us test/teamfood couple of new features under development.
Bug: 173044646
Test: Wifi HAL can read persist.vendor.debug.wifi properties.
Change-Id: Iabd07e72aa5f0d97519a37d0ebb1e0a3458b6d06
This tracing daemon interfaces with perf_events, and is used for
callstack sampling. Currently, we only handle userspace stacks. We
have the ability to collect kernel frame addresses (as unwound
by the kernel itself), but need /proc/kallsyms to symbolize them.
This patch mirrors what was done for traced_probes (ftrace event
kptr symbolization) in aosp/1455337 - the daemon can set a sysprop
that causes "init" to temporarily relax kptr_restrict, then the daemon
can open and read /proc/kallsyms. After the file is parsed, the
kptr_restrict value is restored.
To reiterate, this is confined to userdebug_or_eng due to the reasons
outlined in go/perfetto-kallsyms.
Bug: 173124818
Change-Id: I9077bbfe6fea3318f4c37947a5c455061ca43d8d
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
Any partitions should be able to write this property with build.prop.
This adds a new context for ro.product.property_source_order so it can
be set from any build.prop, e.g. vendor/build.prop, product/build.prop,
etc.
Bug: 172459064
Test: PRODUCT_VENDOR_PROPERTIES can set this property
Change-Id: Ibf85a4ad02d8454f621428b271e8e298067aa126
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: I951d6f993445e8ba11c30a504b8de281fdd93c4a
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
Now that we have an attribute for all app data files, make use of
it. It's cleaner.
The net effect here is a slight loosening of permissions - we now
allow open fds for any app_data_file_type to be passed to a different
process, rather than just app_data_file and privapp_data_file.
Bug: 171795911
Test: presubmits
Merged-In: I4cf812d01577b923efbe1ea3f276c209844d8858
Change-Id: I4cf812d01577b923efbe1ea3f276c209844d8858
