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. 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.
