microdroid_payload needs to open a vsock server, so this change grants
permissions for that. This change also temporarily grants permissions to
get local CID, which should be removed once the RPC binder API supports
getting CID.
Bug: 195381416
Test: atest MicrodroidHostTestCases
Change-Id: I57a603e74d7552e13a83fa4934621e09e13015fd
Previously, the boot process of microdroid was mostly implemented in the
init.rc file. microdroid_manager was started first in the background,
then apexd, apkdmverity, and zipfuse were executed in sequence. However,
in order to correctly implement the app payload verification scheme,
most of the early boot process has to be controlled by
microdroid_manager. Specifically, apkdmverity should be started "after"
the apk roothash is read from the instance disk by microdroid_manager.
As an alternative, we could let apkdmverity the read instance disk by
itself. However, this is undesirable because doing so requires multiple
processes - microdroid_manager and apkdmverity - have access to the
instance disk and more seriously the secret key to decrypt it.
Another alternative is to let microdroid_manager do the dm-verity
configuration which apkdmverity does. This also is considered
undesirable because then we would give the permissions for configuring
dm-verity devices to microdroid_manager which is a long-running daemon
process. Note that apkdmverity is not a daemon process.
This CL introduces a few number of changes which are required to let
microdroid_manager directly control the early boot process:
1) microdroid_manager is allowed to start the services apkdmverity and
zipfuse by using the `ctl.start` sysprop.
2) apkdmverity is allowed to use bootstrap bionic libraries as it is now
executed before APEXd activates the APEXes.
3) A new sysprop `microdroid_manager.apk_roothash` is added. It is
written by microdroid_manager and read by apkdmverity. It contains the
roothash read from the instance disk. This value is not a secret.
4) Another new sysprop `apex_config.done` is added. It is set by init
just after `perform_apex_config` and read by microdroid_manager.
Microdroid_manager uses this to wait until linker configuration is ready
so that it can execute app payloads with the config.
Bug: 193504400
Test: atest MicrodroidHostTestCases
Change-Id: If29ce17d7a6cb4859e8ceeffb321724e7f11bf82
microdroid_manager needs to know its own CID until the full RPC binder
support is landed.
Bug: 191845268
Test: run MicrodroidDemoApp
Test: atest MicrodroidHostTestCases
Change-Id: I8f6c667f0827d1089baa21417c2b0ba382d94d26
With a change in dex2oat to avoid opening /proc/self/fd, this change
removes open and a few other privileges from dex2oat.
Bug: 196404749
Test: ComposHostTestCases
Change-Id: I822c7ef3886a1cde8601e71afa2eb79973cd573c
CAP_SYS_ADMIN is required to mount a filesystem (currently in authfs, a
child process of authfs_service). It seems the parent also needs to be
allowed.
Bug: 194474784
Test: Use the service (from compsvc), no longer seeing the denials
Change-Id: I122734ee9f11899af4d7b647bc3049e4dbdad09e
Microdroid_manager creates a vsock socket and app's output is redirected
to it.
Bug: 195751698
Test: MicrodroidHostTestCases
Change-Id: I66759067169cc97a6c1fc084395761e06c6e20f6
authfs_service is a binder service on microdroid. Upon a request by the
client, the service will create the mount directory, execute authfs to
mount the FUSE, and finally unmount and delete the mount directory.
authfs currently requires more privileges than it should, but it's ok
because the client owns the VM, and all input will be verified by
signatures. But there is plan to keep the privileges isoated in the
service (b/195554831).
Bug: 194717985
Bug: 195554831
Test: Start the service from init, use a test executable to call the
service API. Only observed denial from the test executable.
Change-Id: Ie53aa9e2796433fc3182357039d0b7ba1c0848ef
Microdroid_manager should verify payloads(APK/APEXes). APK is mounted to
dm_device first and then verified. So, microdroid_manager needs to read
it.
Bug: 190343842
Test: MicrodroidHostTestCases
Change-Id: I530fb8d2394952486f0bad7fb3bed770611cd311
This is the only blocker for SELinux denial test on microdroid. Rather
than consuming more time, this temporarily suppresses the audit message
to turn on the test.
Bug: 193118220
Test: atest MicrodroidHostTestCases -c
Change-Id: Id703107cbaae42352bebe34d0a6373f0701c0f6f
keystore uses sqlite3. sqlite3 calls F2FS_IOC_GET_FEATURES. As
microdroid has nothing to do with that, we just suppress the audit.
Bug: 193118220
Test: atest MicrodroidHostTestCases
Change-Id: I1da00d1fd4b7e208e80a1d9bc5f49c21af684516
It's a test tool which is generally run as root, and will be deleted
eventually. It doesn't need its own label; system_file works fine.
We never actually allowed it anything, nor defined a transition into
the domain.
Bug: 194474784
Test: Device boots, no denials
Test: compos_key_cmd run from root works
Change-Id: If118798086dae2faadeda658bc02b6eb6e6bf606
microdroid_payload attribute is for processes meant to be run by
microdroid_manager as a payload. Other than microdroid_payload and
crash_dump, transition from microdroid_manager will not be permitted.
Bug: 191263171
Test: atest MicrodroidHostTestCases
Test: atest ComposHostTestCases
Change-Id: I959a8ad8ed83c8de254d7af61fd30bcbffe6b070
This is necessary (but not sufficient) to allow CompOsTestCase to
run. Without it we have problems because
system/sepolicy/apex/com.android.art-file_contexts references
dex2oat_exec, and we get an error:
SELinux : Context u:object_r:dex2oat_exec:s0 is not valid (left unmapped).
Bug: 194474784
Test: atest CompOsTestCase (with memory fix patched in)
Change-Id: If229b9891c8fb1acce8d0502675c1712bfed180c
