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: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] About XSM/flask
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Wed, 22 Sep 2010 12:33:39 -0400
Delivery-date: Wed, 22 Sep 2010 09:34:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C9A24C8.6090609@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Actac+ktHvbZqIaEh0+re2luLxmzKA==
Thread-topic: [Xen-devel] About XSM/flask
User-agent: Microsoft-Entourage/
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;
            case HVMOP_ETC:
                /* ops that have no security impact */
                return 0;
>           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.


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

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