[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 05.04.2022 19:17, Jason Andryuk wrote: > On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith > <dpsmith@xxxxxxxxxxxxxxxxxxxx> 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. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |