In AVF, virtualizationmanager checks the selinux label of given disk
image for proving whether the given image is edited maliciously.
Existing one(vendor_configs_file, /vendor/etc/*) was too wide to use for this purpose.
Bug: 285854379
Test: m
Change-Id: I6c966c92b238a2262d2eb7f41041ed4c359e9e0a
If we run a VM from an adb shell, e.g. via `vm run`, then we would
like to get the VM console & log sent to the shell console.
That doesn't work unless virtualization manager & crosvm can write to
devpts.
Bug: 286355623
Test: Manual: adb shell, /apex/com.android.virt/bin/vm run-microdroid --debug full
Change-Id: I01b233bc6ad5fba8f333f379af62a03806ae8949
Introduce hypervisor-generic type for VM managers:
vm_manager_device_type.
Bug: 274758531
Change-Id: I0937e2c717ff973eeb61543bd05a7dcc2e5dc19c
Suggested-by: Steven Moreland <smoreland@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Split virtualizationservice policy into rules that should remain with
the global service and rules that now apply to virtmgr - a child process
of the client that runs the VM on its behalf.
The virtualizationservice domain remains responsible for:
* allocating CIDs (access to props)
* creating temporary VM directories (virtualization_data_file, chown)
* receiving tombstones from VMs
* pushing atoms to statsd
* removing memlock rlimit from virtmgr
The new virtualizationmanager domain becomes responsible for:
* executing crosvm
* creating vsock connections, handling callbacks
* preparing APEXes
* pushing ramdumps to tombstoned
* collecting stats for telemetry atoms
The `virtualizationservice_use` macro is changed to allow client domains
to transition to the virtmgr domain upon executing it as their child,
and to allow communication over UDS.
Clients are not allowed to communicate with virtualizationservice via
Binder, only virtmgr is now allowed to do that.
Bug: 250685929
Test: atest -p packages/modules/Virtualization:avf-presubmit
Change-Id: Iefdccd908fc28e5d8c6f4566290e79ed88ade70b
Instead of giving CAP_IPC_LOCK to crosvm, give virtualizationservice
CAP_SYS_RESOURCE so it can modify the rlimit_memlock of itself and its
children. This is done in preparation for running crosvm as a child
process of the requestor, in which case it will not have the option to
use CAP_IPC_LOCK anymore, but it also allows us to set an upper bound on
the amount of pinnable memory if necessary.
Bug: 204298056
Bug: 245727626
Test: atest MicrodroidTestApp
Change-Id: Ic7f161fe4232440a0dd9924d971f22fc053d973b
And allow VS and crosvm access to privapp_data_file, to the same
extent as app_data_file.
Update some comments, move a neverallow to the bottom of the file with
the others.
Bug: 255286871
Test: Install demo app to system/priv-app, see it work without explicit grant.
Change-Id: Ic763c3fbfdfe9b7a7ee6f1fe76d2a74281b69f4f
...and crosvm to access a listener socket when passed to it by file
descriptor from virtualizationservice.
Bug: 235579465
Test: Start a VM
Change-Id: I7e89cfb4fb8a1ce845eaea64a33dbaad6bff9969
The compliance tests rely on this.
Bug: 230660133
Test: run MicrodroidHostTests on a user build
Merged-In: Ic061632d80285182ec2ae7d31f3527948702cf32
Change-Id: Ic061632d80285182ec2ae7d31f3527948702cf32
Some of our CTS tests require that crosvm to have read/write access to
files on /data/local/tmp/virt which is labeled as data_shell_file.
Since CTS tests should pass on user builds, grant the access in user
builds as well.
Note that the open access is still disallowed in user builds.
Bug: 222013014
Test: run cts
Change-Id: I4f93ac64d72cfe63275f04f2c5ea6fb99e9b5874
Allow crosvm to write a VM failure reason to virtualizationservice via the pipe provided.
Fixes this denial: avc: denied { write } for path="pipe:[95872]"
dev="pipefs" ino=95872 scontext=u:r:crosvm:s0
tcontext=u:r:virtualizationservice:s0 tclass=fifo_file
Bug: 220071963
Test: Run VM, no denial.
Change-Id: I3beedc5e715aa33209d3df0cae05f45f31e79e66
Any virtualization service client should be able to use a pipe for the
VM log fds.
We previously had some support for this in crosvm (but appdomain is
the wrong label), but not for virtualizationservice. Instead I've
centralised it in the virtualizationservice_use macro so it applies to
exactly those things that can start a VM.
I've removed read permission from crosvm; it doesn't seem to be
needed, and logically it shouldn't be.
Test: Patch in https://r.android.com/1997004, see no denials
Change-Id: Ia9cff469c552dd297ed02932e9e91a5a8cc2c13f
This was fixed in https://r.android.com/1963701, as it never worked.
This partially reverts commit 2dd48d0400.
Change-Id: I6e7096e20fd594465fb1574b11d6fecc82f5d82f
Remove some allow rules for odsign, since it no longer directly
modifies CompOs files. Instead allow it to run compos_verify_key in
its own domain.
Grant compos_verify_key what it needs to access the CompOs files and
start up the VM.
Currently we directly connect to the CompOs VM; that will change once
some in-flight CLs have landed.
As part of this I moved the virtualizationservice_use macro to
te_macros so I can use it here. I also expanded it to include
additional grants needed by any VM client that were previously done
for individual domains (and then deleted those rules as now
redundant).
I also removed the grant of VM access to all apps; instead we allow it
for untrusted apps, on userdebug or eng builds only. (Temporarily at
least.)
Bug: 193603140
Test: Manual - odsign successfully runs the VM at boot when needed.
Change-Id: I62f9ad8c7ea2fb9ef2d468331e26822d08e3c828
There can be VM disk images that are specific to the underlying SoC.
e.g. in case where SoC-specific hardware is dedicated to a VM and the VM
needs drivers (or HALs) for the hardware.
Don't prevent crosvm from reading such a SoC-specific VM disk images.
Note that this doesn't actually allow crosvm to do that in AOSP. Such an
allow rule could be added in downstreams where such use cases exist.
Bug: 193605879
Test: m
Change-Id: If19c0b6adae4c91676b142324c2903879548a135
The test for the services has been running with selinux disabled. To
turn selinux on, required rules are allowed.
Below is the summary of the added rules.
* crosvm can read the composite disk files and other files (APKs,
APEXes) that serve as backing store of the composite disks.
* virtualizationservice has access to several binder services
- permission_service: to check Android permission
- apexd: to get apex files list (this will be removed eventually)
* Both have read access to shell_data_file (/data/local/tmp/...) for
testing purpose. This is not allowed for the user build.
* virtualizationservice has access to the pseudo terminal opened by adbd
so that it can write output to the terminal when the 'vm' tool is
invoked in shell.
Bug: 168588769
Test: /apex/com.android.virt/bin/vm run-app --log /dev/null
/data/local/tmp/virt/MicrodroidDemoApp.apk
/data/local/tmp/virt/MicrodroidDemoApp.apk.idsig
/data/local/tmp/virt/instance.img
assets/vm_config.json
without disabling selinux.
Change-Id: I54ca7c255ef301232c6e8e828517bd92c1fd8a04
This is necessary to run tests or run VMs manually with SELinux
enforcement enabled.
Bug: 192256642
Test: atest VirtualizationTestCases
Change-Id: I03b12fefa4e79644bd2f3410cc255f923834aca4
