As virtualizationmanager holds references to IBoundDevice returned by
vfio_handler, virtualizationmanager should also have permission to
binder_call.
Bug: 278008519
Test: boot microdroid with assigned devices
Change-Id: I7b87de099b0731c386666cec215807dc39d8c89c
Allow r_file_perms rather than just open+read, mainly because I saw
this denial:
avc: denied { getattr } for comm="binder:11247_2"
path="/sys/firmware/devicetree/base/avf/guest/common/log"
dev="sysfs" ino=16469 scontext=u:r:virtualizationmanager:s0
tcontext=u:object_r:sysfs_dt_avf:s0 tclass=file permissive=0
Also refactor slightly in microdroid_manager.te.
Test: TH
Change-Id: If2963441b3490a502c293c7a7cdd204d9db7d48a
It ferries SecretManagement messages to/from Sk. Reflect this is
sepolicies.
Test: With topic, check selinux denials
Bug: 291213394
Change-Id: Ia0d25e46232d56c59fb18f8642767bfa2d5ffab1
It ferries SecretManagement messages to/from Sk. Reflect this is
sepolicies.
Test: With topic, check selinux denials
Bug: 291213394
Change-Id: I0acc06424eb834d66a85f9d4f6b8b632d95c4190
If malicious process in the host overwrites microdroid vendor image,
unexpected behavior could be happened.
Bug: 285854379
Test: adb shell /apex/com.android.virt/bin/vm run-microdroid --vendor /vendor/etc/avf/microdroid/microdroid_vendor.img
Change-Id: I18ce5112b75b2793c85bb59c137715beb602a5f3
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
virtualizationmanager may handle some AVF debug policies for unproteted VM.
Bug: 243630590
Test: Run unprotected VM with/without ramdump
Change-Id: I2941761efe230a9925d1146f8ac55b50e984a4e9
Commit 2d736569e716b5c143f296ae124bcfed9630a4d2 improved the logging
in virtualization service by attempting to get the real path from
/proc/self/fd/N for various files.
However, CompOS stores its log files in a directory
(/data/misc/apexdata/...) which VS has no access to, triggering an
SELinux denial:
avc: denied { search } for name="apexdata"
scontext=u:r:virtualizationmanager:s0
tcontext=u:object_r:apex_module_data_file:s0 tclass=dir
Suppress this denial, since it causes no harm (we just don't log the
real path).
Bug: 264496291
Bug: 251751405
Test: composd_cmd test-compile;
see no denials
Change-Id: Ia55e593c0c0735b8f3085a964f0c789c177375f2
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
