This commit adds necessary permissions for ot-rcp to bind
to a network interface specified by its address or name.
Test: presubmit
Bug: 329188649
Change-Id: I6731df79c04eeeb2c39017b99b9c2acf315256e2
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 will allow the CTS get the WifiScanner to test. Also WifiScanner is
a system API and all APIs are protected by the priviliged permissions.
Bug: 339527374
Test: CtsWifiTestCases
Change-Id: Ic06a5804fa81a952e9e8792e93df489a9d47d521
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
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
