[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged
On 3/31/22 09:16, Jason Andryuk wrote: > On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith > <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> There are now instances where internal hypervisor logic needs to make >> resource >> allocation calls that are protected by XSM checks. The internal hypervisor >> logic >> is represented a number of system domains which by designed are represented >> by >> non-privileged struct domain instances. To enable these logic blocks to >> function correctly but in a controlled manner, this commit introduces a pair >> of privilege escalation and demotion functions that will make a system domain >> privileged and then remove that privilege. >> >> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> >> --- >> xen/include/xsm/xsm.h | 22 ++++++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> >> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h >> index e22d6160b5..157e57151e 100644 >> --- a/xen/include/xsm/xsm.h >> +++ b/xen/include/xsm/xsm.h >> @@ -189,6 +189,28 @@ struct xsm_operations { >> #endif >> }; >> >> +static always_inline int xsm_elevate_priv(struct domain *d) >> +{ >> + if ( is_system_domain(d) ) >> + { >> + d->is_privileged = true; >> + return 0; >> + } >> + >> + return -EPERM; >> +} > > These look sufficient for the default policy, but they don't seem > sufficient for Flask. I think you need to create a new XSM hook. For > Flask, you would want the demote hook to transition xen_boot_t -> > xen_t. That would start xen_boot_t with privileges that are dropped > in a one-way transition. Does that require all policies to then have > xen_boot_t and xen_t? I guess it does unless the hook code has some > logic to skip the transition. I am still thinking this through but my initial concern for Flask is that I don't think we want dedicated domain transitions directly in code. My current thinking would be to use a Kconfig to use xen_boot_t type as the initial sid for the idle domain which would then require the default policy to include an allowed transition from xen_boot_t to xen_t. Then rely upon a boot domain to issue an xsm_op to do a relabel transition for the idle domain with an assertion that the idle domain is no longer labeled with its initial sid before Xen transitions its state to SYS_STATE_active. The one wrinkle to this is whether I will be able to schedule the boot domain before allowing Xen to transition into SYS_STATE_active. > For the default policy, you could start by creating the system domains > as privileged and just have a single hook to drop privs. Then you > don't have to worry about the "elevate" hook existing. The patch 2 > asserts could instead become the location of xsm_drop_privs calls to > have a clear demarcation point. That expands the window with > privileges though. It's a little simpler, but maybe you don't want > that. However, it seems like you can only depriv once for the Flask > case since you want it to be one-way. This does simplify the solution and since today we cannot differentiate between hypervisor setup and hypervisor initiated domain construction contexts, it does not run counter to what I have proposed. As for flask, again I do not believe codifying a domain transition bound to a new XSM op is the appropriate approach. v/r, dps
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |