mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Daniel P. Smith
3007efadf7
The current flow for initial SID assignment is that the function flask_domain_alloc_security() allocates the security context and assigns an initial SID based on the limited state information it can access. Specifically the initial SID is determined by the domid of the domain, where it would assign the label for one of the domains the hypervisor constructed with the exception of initial domain (dom0). In the case of the initial domain and all other domains it would use the unlabeled_t SID. When it came to the SID for the initial domain, its assignment was managed by flask_domain_create() where it would be switched from unlabeled_t to dom0_t. This logic worked under the assumption that the first call to flask_domain_create() would be the hypervisor constructing the initial domain. After which it would be the toolstack constructing the domain, for which it is expected to provide an appropriate SID or else unlabeled_t would be used. The issue is that the assumptions upon which the current flow is built were weak and are invalid for PV shim and dom0less. Under the current flow even though the initial domain for PV shim is not set as privileged, flask would label the domain as dom0_t. For dom0less, the situation is two-fold. First is that every domain after the first domain creation will fail as they will be labeled as unlabeled_t. The second is that if the dom0less configuration does not include a "dom0", the first domain created would be labeled as dom0_t. This commit only seeks to address the situation for PV shim, by including a check for xenboot_t context in flask_domain_alloc_security() to determine if the domain is being constructed at system boot. Then a check for is_privilged and pv_shim is added to differentiate between a "dom0" initial domain and a PV shim initial domain. The logic for flask_domain_create() was altered to allow the incoming SID to override the initial label. This allows a domain builder, whether it is a toolstack, dom0less, or hyperlaunch, to provide the correct label for the domain at construction. The base policy was adjusted to allow the idle domain under the xenboot_t context the ability to construct domains of both types, dom0_t and domu_t. This will enable a hypervisor resident domain builder to construct domains beyond the initial domain, Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com>