[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


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 6 Apr 2022 09:06:59 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dCc5MjGVuClMclOm/PARP1lH4sH4o1x+CK2Q9ashh1w=; b=hUop2NrZz4W0ZG9s9QicSFfGmn/1D7rJLaCcFSFRQh+klIr4L3etAQP5pgC9Lc3M9ZSyF0NZ+ses3EQsFln5jvkfblMrRzFXdM1TujQS4TS/Y+gNSE6LbIdqvQnj4fIAgRVRnA6NaT+Ab1DkrlubN2PS1uC++XnwkgeqMGvJyTLrkbMaoMWhvxU2FOcdCu9oCHmJ2ematmYPkGToo70a0Kucw3xBfy1MXu25GJNYUAXrbeJZa0XD7UNLJZJanMb/wSe9sqdU1haC9eeFZCV4RP7JTpuopAWDtQSxbjoQHBerECzM0LZFqCveY4PqqNbvkKke29F72lQegEdz3Pm7xw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A900OXtgcGkG0FOs9hXsAz/yppGaYb7mm5vcXB7pdcdDtSgGLvkJwddMoZ/UW7JVyCKKLa4n5alhqK9SHl3Fe8xyV34rF8M+iqVGLlbwtTCkWFDpb1y13lTCPHcaqvpDjdRCFGpp++Z5o882bwjhwDzZ94T/NyOPiEBXzQ2YBwhXOPVnGNSkr2UKlFXQFUN+8jombXLS6QI8OM1z2FYazGGl7uGm2T9Qc2DjSvGrmRC0k62Uk2AIGZ+cPGBTScAxt8oEP82FrnNyo6HLggwpySzSm6AcZ3augJD3cvZAr2wKumPJeks3Nu8WYDhMtMn2e1XWaY22oPCczEIprl91kA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Scott Davis <scott.davis@xxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 06 Apr 2022 07:07:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

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