[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xsm: also panic upon "flask=enforcing" when XSM_FLASK=n



Andrew Cooper writes ("Re: [PATCH] xsm: also panic upon "flask=enforcing" when 
XSM_FLASK=n"):
> On 29/05/2020 10:34, Jan Beulich wrote:
> > While the behavior to ignore this option without FLASK support was
> > properly documented, it is still somewhat surprising to someone using
> > this option and then still _not_ getting the assumed security. Add a
> > 2nd handler for the command line option for the XSM_FLASK=n case, and
> > invoke panic() when the option is specified (and not subsequently
> > overridden by "flask=disabled").
> >
> > Suggested-by: Ian Jackson <ian.jackson@xxxxxxxxxx>
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I'm very tempted to nack this outright, lest I remind both of you of the
> total disaster that was XSA-9, and the subsequent retraction of the code
> which did exactly this.

You are right to remind me of, well, whatever it is you are trying to
remind me of, since I'm afraid I don't know what you mean ...  Do you
really mean XSA-9 ?  I went at looked it up and the connection eludes
me.

> If you want to do something like this, prohibit creating guests so the
> administrator can still log in and unbreak, instead of having it
> entering a reboot loop with no output.  The console isn't established
> this early, so none of this text makes it out onto VGA/serial.

Certainly a silent reboot loop would be very unhelpful.  I think if
Xen were to actually print something to the serial console that would
be tolerable (since the administrator can then adjust the boot command
line), but your suggestion to prohibit guest creation would be fine
too.

Thanks,
Ian.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.