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