On 06.04.2022 11:09, Roger Pau Monné wrote: > On Wed, Apr 06, 2022 at 10:48:23AM +0200, Jan Beulich wrote: >> On 06.04.2022 10:46, Roger Pau Monné wrote: >>> On Wed, Apr 06, 2022 at 09:06:59AM +0200, Jan Beulich wrote: >>>> On 05.04.2022 19:17, Jason Andryuk wrote: >>>>> On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith >>>>> <dpsm...@apertussolutions.com> wrote: >>>>>> On 3/31/22 09:16, Jason Andryuk wrote: >>>>>>> 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. >>>>> >>>>> This hard coded domain transition does feel a little weird. But it >>>>> seems like a natural consequence of trying to use Flask to >>>>> deprivilege. I guess the transition could be behind a >>>>> dom0less/hyperlaunch Kconfig option. I just don't see a way around it >>>>> in some fashion with Flask enforcing. >>>>> >>>>> Another idea: Flask could start in permissive and only transition to >>>>> enforcing at the deprivilege point. Kinda gross, but it works without >>>>> needing a transition. >>>> >>>> I don't think that would be right. Logically such behavior ought to be >>>> mirrored to SILO, and I'll take that for the example for being the >>>> simpler model: Suppose an admin wants to disallow communication >>>> between DomU-s created by Xen. Such would want enforcing when creating >>>> those DomU-s, despite the creator (Xen) being all powerful. If the >>>> device tree information said something different (e.g. directing for >>>> an event channel to be established between two such DomU-s), this >>>> should be flagged as an error, not be silently permitted. >>> >>> I could also see this argument the other way around: what if an admin >>> wants to disallow domUs freely communicating between them, but would >>> still like some controlled domU communication to be possible by >>> setting up those channels at domain creation? >> >> Well, imo that would require a proper (Flask) policy then, not SILO mode. > > But when creating such domains in SILO mode from dom0, dom0 would be > allowed to create and bind event channels to the created domains, even > if the domain themselves are not allowed the operation. > > That's because the check in evtchn_bind_interdomain() is done against > 'current' and not the domain where the event channel will be bound.
Yes and no - the check is against current, but that's because communication is established between current ( == ld) and rd. The function in its present shape simply can't establish a channel between two arbitrary domains. Jan > Maybe such check should instead take 3 parameters: current context > domain, domain to bind the event channel to and remote domain on the > other end of the event channel. > > Thanks, Roger. >
