We need to maintain the Pre-reboot Dexopt state across system server
crashes and restarts, but not across reboots. System properties are
suitable for this use case. The state includes whether the job has run
and the OTA slot.
Bug: 311377497
Change-Id: I527d4ba6064c1600d97ce2efc8be211b9460a8f0
Test: Presubmit
Define new classes and access vectors recognised by the kernel.
Bug: 340491179
Test: boot and check logs for undefined class or permission
Change-Id: I9b32916ea231cf396aa326ed7e08cb14e4eb2c9b
dumpstate may be executed by apps in different domains. Notably, a
system_app needs to be able to save the output in its own directory.
avc: denied { append } for comm="binder:575_1" dev="dm-50"
ino=10712 scontext=u:r:dumpstate:s0
tcontext=u:object_r:system_app_data_file:s0 tclass=file
Using the app_data_file_type attribute to capture all the potential app
data types. For info, the current Cuttlefish policy has:
$ seinfo -x -a app_data_file_type cf_policy
attribute app_data_file_type;
app_data_file
bluetooth_data_file
nfc_data_file
privapp_data_file
radio_data_file
sdk_sandbox_data_file
shell_data_file
storage_area_app_dir
storage_area_content_file
storage_area_dir
system_app_data_file
Test: bugreport
Change-Id: I7685c1fcdb3896c44fe44008b1b262c3f1e90a01
When odsign spawns compos_verify it has our stdin/out connected to its
console. But none of the VM processes use stdin/out at all; they log
to logcat instead.
So instead of allowing the access (which immediately leads to the same
denials in virtualizationmanager), just suppress the audit logs.
Bug: 293259827
Test: Exercise isolated compilation successfully with no denials seen.
Change-Id: I454bb2fe106b656a9695511cbf09350402b30bdd
Pixel has /dev/usb-ffs/adb, /dev/usb-ffs/mtp, and /dev/usb-ffs/ptp in
type functionfs.
Bug: 311377497
Change-Id: Id9388a0d420c712962804f6441c86cfb3c4e9e62
Test: adb shell cmd jobscheduler run android 27873781
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
In practice only bpf programs are critical to device security...
Normally there is basically no use for creating bpf maps outside
of the bpfloader, since they have to be tied directly into the bpf
programs (which is only ever done by the bpfloader during the boot
process) to be of any use.
This means that bpf maps created after the bpfloader is done,
can't actually be used by any bpf code...
Hence we had this restriction.
However, map-in-map support changes this:
It becomes possible to define a boot-time (bpfloader loaded)
bpf program which accesses an (initially empty) outer map
(created by the bpfloader).
This outer map can be populated with inner maps at run time by various
bpf using userspace code. While it can be populated with bpfloader
created 'static' maps, it also makes sense to be able to create/destroy
these inner maps on demand 'dynamically'.
This allows bpf map memory utilization to be driven by actual runtime
device needs. For example scaling with the number of users, apps,
or connected networks.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I93223c660463596c9e50065be819e2fd865da923
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
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
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
Since Android S, we started to enforce the debugfs restrictions. However,
GSI had it turned off (PRODUCT_SET_DEBUGFS_RESTRICTIONS := false) in order
to support pre-S vendor images.
This has an undesirable side effect that the restriction is turned off even
for S+ vendors.
This CL fixes it by
1) re-enabling the restriction for GSI and
2) manually adding the debugfs permissions only to the compat cil for the
pre-S (29 and 30) vendors, effectively turning the restriction off for
them.
Bug: 330671086
Test: build
Test: run neverallow CTS
Change-Id: I5cd554b1b9f729a540e6b0f2aa0662091b691f0c
