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

Re: [PATCH] XSM/domctl: Fix permission checks on XEN_DOMCTL_createdomain


  • To: "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>
  • From: Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 30 Jul 2024 07:29:23 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1722338970; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=3n0fFlr23F33EHRPuG52P3Z9RgdRTwzGTNI2w+2PThs=; b=Ax/BKP3OP72pqMfv/3C0rPb1xBatb4B7owOEAy9catvZ9XPrVZm62328JdGh7MDUE+LJj9Z/OceQ9J2Elb/iOhGn3rArhOs029KqDBHCYw3VsPpP9QPfP/i+kvc84Yu29lC/T7goCn77Y4tn84wdO7VX3YrCEjHRflnHguVXwv0=
  • Arc-seal: i=1; a=rsa-sha256; t=1722338970; cv=none; d=zohomail.com; s=zohoarc; b=Rgq9EhtoexiuQDu1Fbnu8DGiodgcmVVjR5NbtTJHC+wgGChb7KVzuBvGohQRcwF/3jdNodpnLFY7gO4BCgwW5AVTvKxs9OIoke8p+Pfh8ovFuTd95D/IrPOtyDchyGbB4E6T5Cwr5heZ4FrYpGY6NpeJ3B0V25m6+A1kjHrgB/I=
  • Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Ross Lagerwall" <ross.lagerwall@xxxxxxxxxx>, "Jan Beulich" <JBeulich@xxxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, "Julien Grall" <julien@xxxxxxx>
  • Delivery-date: Tue, 30 Jul 2024 11:29:41 +0000
  • Importance: Medium
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

---- On Mon, 29 Jul 2024 12:26:51 -0400 Andrew Cooper  wrote ---

 > The XSM checks for XEN_DOMCTL_createdomain are problematic.  There's a split 
 > between xsm_domctl() called early, and flask_domain_create() called quite 
 > late 
 > during domain construction. 
 >  
 > All XSM implementations except Flask have a simple IS_PRIV check in 
 > xsm_domctl(), and operate as expected when an unprivileged domain tries to 
 > make a hypercall. 
 >  
 > Flask however foregoes any action in xsm_domctl() and defers everything, 
 > including the simple "is current permitted to create a a domain" check, to 
 > flask_domain_create(). 
 >  
 > As a conseqeuence, when XSM Flask is active, and irrespective of the policy 
 > loaded, all domains irrespective of privilege can: 
 >  
 >  * Mutate the global 'rover' variable, used to track the next free domid. 
 >  Therefore, all domains can cause a domid wraparound, and combined with a 
 >  volentary reboot, choose their own domid. 
 >  
 >  * Cause a reasonable amount of a domain to be constructed before ultimately 
 >  failing for permission reasons, including the use of settings outside of 
 >  supported limits. 
 >  
 > In order to remedate this, pass the ssidref into xsm_domctl() and at least 
 > check that the calling domain privileged enough to create domains. 
 >  
 > This issue has not been assigned an XSA, because Flask is experimental and 
 > not 
 > security supported. 
 >  
 > Reported-by: Ross Lagerwall ross.lagerwall@xxxxxxxxxx> 
 > Signed-off-by: Andrew Cooper andrew.cooper3@xxxxxxxxxx> 
 > --- 
 
Acked-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>



 


Rackspace

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