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

Re: [PATCH 2/2] flask: implement xsm_transtion_running


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 20 Apr 2022 15:51:03 -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=1650484309; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=nLGKb2nHoVHpxHpT6pxINKx03WgbTw/0e+pGu/rhNj4=; b=l5nB+38Ijziq98xzw2IDx0zD24C72iZrDh0tF+q7syFilpo1QV9Vgz7wgFJgqQBXdTyOC556gzl6f843GMXrhtzNgQOCsZOtiHef80RM4I/DaBTBL4lJ9WT3WNtZ7KB4i0dDbdW6iKPxmaSMhTDDMVGcP7X/3/QfrIdPxts2akw=
  • Arc-seal: i=1; a=rsa-sha256; t=1650484309; cv=none; d=zohomail.com; s=zohoarc; b=iem/k3jWNpm7hSecSJuydASpv/zLQ1Wy8Ztn7L+oh+I5HcpRLDaWr+IMKlXFk4S3ZWVeegV094hDpcn/0YHHIxwEfrdpPonFdm1GosCGNlRVC/sH9P9HFmlZnTyl/NCsx1+cQ0UOV5QIl9fva8KqkhsEKCSCgAxhp4cuUy5bw4M=
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Scott Davis <scott.davis@xxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Wed, 20 Apr 2022 19:52:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 4/20/22 14:07, Jason Andryuk wrote:
> On Wed, Apr 20, 2022 at 1:03 PM Daniel P. Smith
> <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> This commit implements full support for starting the idle domain privileged 
>> by
>> introducing a new flask label xenboot_t which the idle domain is labeled with
>> at creation.  It then provides the implementation for the XSM hook
>> xsm_transition_running to relabel the idle domain to the existing xen_t flask
>> label.
>>
>> In the reference flask policy a new macro, xen_build_domain(target), is
>> introduced for creating policies for dom0less/hyperlaunch allowing the
>> hypervisor to create and assign the necessary resources for domain
>> construction.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>> ---
> 
>> @@ -188,6 +188,7 @@ static int cf_check flask_domain_alloc_security(struct 
>> domain *d)
>>
>>  static void cf_check flask_domain_runtime_security(void)
>>  {
>> +    struct domain_security_struct *dsec;
>>      struct domain *d = current->domain;
>>
>>      if ( d->domain_id != DOMID_IDLE )
>> @@ -198,6 +199,9 @@ static void cf_check flask_domain_runtime_security(void)
>>       * set to false for the consistency check(s) in the setup code.
>>       */
>>      d->is_privileged = false;
>> +
>> +    dsec = d->ssid;
>> +    dsec->sid = SECINITSID_XEN;
> 
> I think you also want
>    dsec->self_sid = dsec->sid;
> so self also changes to xen_t.

Erg, thanks for the catch.

> Otherwise I think it looks good,
> 
> I was wondering if you were going to require xenboot_t -> xen_t
> permissions, but manually setting the sid fields side-steps that.
> That seems nicer than requiring policy rules for the transition.

I was considering it but as I was reflecting on the discussions that
were had, this is a one-time, one-way transition. Combine that with the
fact that xenboot_t has to be an initial sid (fixed/permnant type) for
Xen's flask policy, there is no need to require a transition rule in the
policy that can never be changed. And yes, it helps makes things much
simpler.( ^_^)

> Hmmm, cross referencing other flask code, often after assigning
> self_sid there is this call to potentially re-calculate it:
>     security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
> &dsec->self_sid);
> 
> But it isn't used for system domains, so omitting it seems fine.

Hmm, now you have me concerned about decisions residing in the avc from
accesses made during domain creation. Let me double check that, but I
think it will be needed. I believe the reason it was not needed for the
system domains because prior to this no access decisions were made
before the domains were labeled.

v/r,
dps



 


Rackspace

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