This is used to determine if the device has been in 16k page size mode
to help debug issues with that.
Test: debuggerd_test with ro.misctl.16kb_before="1"
Bug: 335247092
Change-Id: I7b5fcd39cc5b3247d866814fbcf53299d68846c2
The dynamic linker needs to read this node to determine how it should
load ELF files.
Allow the node to be enabled/disabled by init.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Test: Free Fire Chaos App launches
Test: no avc deined in logcat
Change-Id: I2b35d6aebe39bf3e1e7489b47f23a817e477ef72
During storage migration, we need to route aconfig flag write requests
from settingsprovider to aconfig storage daemon via aconfigd unix domain
socket.
Bug: b/312444587
Test: m and avd
Change-Id: I051d1ed42bf51f2ebd90cbd590237cd9213f0bde
These have been added to the kernel and to Android sepolicy, but not
yet here. This doesn't make much difference, but it does avoid some
(harmless) warnings at policy load time.
While I'm here, remove some userspace classes which don't exist in
Microdroid and probably never will.
Bug: 215093641
Test: Policy still builds; TH
Change-Id: Id2f778919e492162c1a7d77822d74d7978522118
This is a no-op now but it will make vintf finalization easier because
we'll only need system/sepolicy changes.
Bug: 337978860
Test: atest CtsSecurityHostTestCases
Change-Id: I242dcad7511e7c880b1e5434ba3de622f56bc1b3
Introuducing vendor_boot_ota_file which will be used to allow
reading OTAs from /vendor/boot_otas when BOARD_16K_OTA_MOVE_VENDOR := true
is set. These OTAs will be read from settings app(system_app) and update
engine.
Test: m, m Settings && adb install -r $ANDROID_PRODUCT_OUT/system_ext/priv-app/Settings/Settings.apk
Bug: 335022191
Change-Id: Ie42e0de12694ed74f9a98cd115f72d207f67c834
Installd needs the read permission on storage area
key directories. This only comes up in testing when the tests
are rerun on the same device.
Bug: 325129836
Test: atest StorageAreaTest
Change-Id: I74c776c52d66492552aaf8b61c7591fb19194f7a
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: I267031c68f2157a679a1fceb3ae684bb7580c77c
We are adding the ability for apps to create "storage areas", which are
transparently encrypted directories that can only be opened when the
device is unlocked.
This CL makes the required SELinux policy changes.
First, assign the type "system_userdir_file" to the new top-level
directory /data/storage_area (non-recursively). This is the same type
used by the other top-level directories containing app data, such as
/data/user, and it restricts access to the directory in the desired way.
Second, add new types to represent an app's directory of storage areas,
the storage areas themselves, and their contents:
`storage_area_app_dir`, `storage_area_dir`, and
`storage_area_content_file` respectively.
All are `app_data_file_type`s.
The directory structure and their associated labels is as follows (note
that they also all get the categories of the user+package):
/data/storage_area/userId/pkgName
storage_area_app_dir
/data/storage_area/userId/pkgName/storageAreaName
storage_area_dir
/data/storage_area/userId/pkgName/storageAreaName/myFile.txt
storage_area_content_file
/data/storage_area/userId/pkgName/storageAreaName/mySubDir
storage_area_content_file
These new types allow us to restrict how and which processes interact
with storage areas.
The new type for the contents of storage areas allows us to add new,
desirable restrictions that we cannot add to the more general
`app_data_file` type in order to maintain backwards-compatibility,
e.g., we block apps from executing any files in their storage areas.
Third, allow:
-- vold_prepare_subdirs to create and delete
storage areas on behalf of apps, and assign them the SElinux type
`storage_area_dir`
i.e. create directories
/data/storage_area/$userId/$pkgName/$storageAreaName
-- vold to assign encryption policies to storage area directories
-- installd to create an app's directory of storage areas on app
install, and delete them on app uninstall, and assign them the SElinux
type `storage_area_app_dir`,
i.e. directories /data/storage_area/$userId/$pkgName
We also add a new SELinux type to represent the storage area encryption
keys: `storage_area_key_file`.
The keys are created by vold on storage area creation, and deleted
either by vold if an app calls
the `deleteStorageArea` API function explicitly, or by installd on
app uninstall.
These keys are stored in `/data/misc_ce/$userId/storage_area_keys`,
and only installd and vold have access to them.
Bug: 325121608
Test: atest StorageAreaTest
Change-Id: I74805d249f59226fc6963693f682c70949bfad93
An APK installing with .idsig gets fs-verity enabled during the package
install. As a step of package install, a package verifier may inspect
the APK. A v4 signature check requires calling FS_IOC_MEASURE_VERITY.
This change gives priv_app the permission (which appdomain already has).
Bug: 337307333
Test: no longer seeing the verifier error
Change-Id: I49b721f229c30677f633dc1e425022ac54801668
at /sys/kernel/mm/lru_gen/enabled. This can be inferred without reading
the file anyways. Writes remain restricted to init.
Test: adb shell cat /sys/kernel/mm/lru_gen/enabled
Bug: 335516770
Change-Id: Ibc8d86f932ecad21c6a07b44aad3517c22fa7843
The neverallow parser has a bug where it cannot parse multiline neverallow
rules that have inline comments. For example (taken from the bug description):
```
neverallow appdomain
system_server:udp_socket
{accept append bind create ioctl listen lock name_bind relabelfrom relabelto setattr shutdown };
```
Initially, the plan to fix this was to use the existing `avrule_read` function the
libsepol parser, however this function expects a compiled `policy` file that represents
the policies to be read in, while the neverallow parser reads from a `.te` file or a string.
This CL implements a fix to this parsing issue by pre-parsing the string
(either read in from a file or passed in as a string directly) and removing
the comments, before proceeding with the parsing as before.
Bug: 334697757
Test: atest android.security.cts.SELinuxNeverallowRulesTest
Change-Id: Ica67dedc23ca9c8b5ba8566198b6bfa785780921
Without this check, a release build may accidentally include additional
public types and attributes after "freeze".
Also this adds a detailed error message for how to fix.
Bug: 296875906
Bug: 330670954
Test: m selinux_policy
Change-Id: Ib43d8e1759ee7426f523042f44e7120e97ae0dd9
To prevent these types from being released in 24Q3, which must be same
as 202404 release.
Bug: 330670954
Test: build
Change-Id: Ibb124fbb069f2025a572bc09c73c241f808676c3
selinux_policy_system is in Android.mk. selinux_policy_system_soong is a
phony module in Android.bp for Soong built system images.
Bug: 329208946
Test: m aosp_cf_system_x86_64
Change-Id: If101155c5a706925d52593bab648b878b075f7f2
'starting_at_board_api' macro is added to guard system/sepolicy/public
types and attributes. The macro will work only when compiling vendor/odm
sepolicy. When compiling platform sepolicy (system / system_ext /
product), rules will always be included, regardless of board API level.
Policy authors should guard new public types and attributes with this
macro, similar to LLNDK. The new types and attributes will be exposed
since next vFRC release.
Bug: 330671090
Test: manually build with various board API level, see output
Change-Id: I03c601ce8fe1f77c7608dc488317d20276fd2d47
