This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] About XSM/flask

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] About XSM/flask
From: Jean Guyader <jean.guyader@xxxxxxxxx>
Date: Wed, 22 Sep 2010 21:29:32 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 22 Sep 2010 13:30:22 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wCjYHoqPuI99zskXg9KvsjJdwBXULrlksCMvqNmHaSc=; b=LKCLSrzEheubnpLw2cRiIwX1LwOTBMNBaeZ6LlaIBgfMp6z+JIlOTeVdH6Kdge12m4 mTpWqmoQNCV5E9FTCcdfhigKDvaYG80nwhExSVdEN1Q7/frVlumzY210jIjNnOrAx3Vz OVJi4/2xrhbqt4wI0/sVH+alZFI3CzE2YTD0Y=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ry/sCW7P1eTu2HMFgIJDm0JWWRTJZjx8wdCW0BDBqqjUdNwtAJpyFWpnc0xO6jcSV8 acu4D7sHAuTHNfwIXQthNo15S8KE6HSobgPnA7PhEGyi2gleIvomR23pZ4qegBH5Wlgx TCTQOMGPA4wqToV7muAMTdH1Lhs3nQr9CzgG0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8BFA823.5051C%gscoker@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C9A24C8.6090609@xxxxxxxxxx> <C8BFA823.5051C%gscoker@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I have a question on this piece of code too.

Why do we return EPERM in this switch case statement and not ENOENT?
(It actually concerns anyway other switch case statement here the operation
isn't understood).

The idea would be to have something on the top of the ops that will
decide to turn
a ENOENT into a EPERM in non permissive mode and a ENOENT into a 0 in
permissive mode. This wrapper function could advertise as a warning all the
unknown operations and it will make updating the xsm code easier in case
we got out of sync.

But it's probably looking for details at this point, and it means
going through all
the code to change EPERM into ENOENT.


On 22 September 2010 17:33, George S. Coker, II <gscoker@xxxxxxxxxxxxxx> wrote:
> This is a bug.  You should be able to run this in permissive mode without a
> problem.  There have been some updates and extensions to this section since
> this check was originally implemented.  The other ops may or may not be
> important here.  Flask should be updated to track the other ops but it may
> not be necessary to associate each op with a unique permission or any
> security check at all.  Something like this,
>>           case HVMOP_set_param:
>            case HVMOP_set_XX:
>            case HVMOP_set_YY:
>>               perm = HVM__SETPARAM;
>>           break;
>>           case HVMOP_get_param:
>            case HVMOP_get_XX:
>            case HVMOP_get_YY:
>>               perm = HVM__GETPARAM;
>>           break;
>            case HVMOP_ZZ:
>                /* security relevant but not a get or set capability */
>                perm = HVM__ZZ;
>            break;
>            case HVMOP_ETC:
>                /* ops that have no security impact */
>                return 0;
>            break;
>>           default:
>>               return -EPERM;
> would address the issue, allow future checks and maintain the original
> intent of protecting against a potentially illegal op being passed through.
> If all the ops can reasonably be paired as get/set, one could just implement
> the above as a patch but recognize the loss of granularity as all get(s) or
> set(s) will be treated as equivalents in the policy.  Deeper thought is
> required to extend the granularity on a per op basis.
> George
> On 9/22/10 11:46 AM, "Jean-Edouard LEJOSNE"
> <jean-edouard.lejosne@xxxxxxxxxx> wrote:
>>   Hi!
>> I've got some trouble with XSM/flask recently.
>> Basically, it blocks stuffs when not enforced, which is not (?) supposed to
>> happen.
>> The problem is actually pretty simple when looking at the code.
>> As an example, here is a function from xen/xsm/flask/hooks.c :
>> static int flask_hvm_param(struct domain *d, unsigned long op)
>> {
>>       u32 perm;
>>       switch ( op )
>>       {
>>           case HVMOP_set_param:
>>               perm = HVM__SETPARAM;
>>           break;
>>           case HVMOP_get_param:
>>               perm = HVM__GETPARAM;
>>           break;
>>           default:
>>               return -EPERM;
>>       }
>>       return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
>> }
>> As it is pretty obvious, if "op" is not "HVMOP_set_param" or
>> "HVMOP_get_param", XSM will deny the action, even if we are in permissive
>> mode.
>> It is currently a problem for us because, for this particular function
>> at least, we use other values of "op" (for dirty bit tracking).
>> I think in that case, flask should just print a warning and return 0
>> when in permissive mode.
>> The only other solution I see is to make sure every possible values are
>> treated by flask, and that it's maintained that way, which is probably a
>> pain.
>> So my question is : is there something that should be done about that? Is the
>> current behaviour mandatory for some reason I didn't think about?
>> Thanks,
> --
> George S. Coker, II <gscoker@xxxxxxxxxxxxxx>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>