[v2,1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
diff mbox

Message ID 20160112163712.GB17685@char.us.oracle.com
State New, archived
Headers show

Commit Message

Konrad Rzeszutek Wilk Jan. 12, 2016, 4:37 p.m. UTC
On Mon, Jan 11, 2016 at 09:17:57AM -0700, Jan Beulich wrote:
> >>> On 11.01.16 at 17:01, <konrad.wilk@oracle.com> wrote:
> > On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
> >> >>> On 08.01.16 at 18:31, <konrad.wilk@oracle.com> wrote:
> >> >> >> > The rest: XENVER_[version|capabilities|
> >> >> >> > parameters|get_features|page_size|guest_handle] behave
> >> >> >> > as before - allowed by default for all guests.
> >> >> >> > 
> >> >> >> > This is with the XSM default policy and with the dummy ones.
> >> >> >> 
> >> >> >> And with a non-default policy you now ignore one of the latter
> >> >> >> ops to also get denied.
> >> >> > 
> >> >> > No, but that is due to the 'deny' being only checked for certain subops.
> >> >> 
> >> >> To me this reply seems contradictory in itself: The "no" doesn't
> >> >> seem to match up with the rest.
> >> >> 
> >> >> > I think what you are saying is that for XENVER_[version|capabilities|
> >> >> > parameters|get_features|page_size|guest_handle] we should not have any
> >> >> > XSM checks as they serve no purpose (which is what I had in the earlier
> >> >> > versions of this patch). However Andrew mentioned that he would
> >> >> > like _ALL_ of the sub-ops to be checked for.
> >> >> 
> >> >> And I agree with Andrew, hence my earlier comment above (with
> >> >> the reply I can't really make sense of).
> >> > 
> >> > I am all confused now.
> >> > 
> >> > There are two parts here:
> >> >  a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle
> >> >    without any hinderance. For XENVER_commandline and XENVER_buildid
> >> >    they are evaluated.
> >> > 
> >> >  b) Acting on the XSM check. For most of them we cannot actually return
> >> >    -EFAULT and MUST return either an valid value or some form of a string.
> >> >    
> >> >    The ones for which we could return '<denied>' were changeset, compile_info,
> >> >    commandline, extraversion. To make it simpler we only do it for
> >> >    commandline.
> >> > 
> >> > In essence we have an XSM check which is ignored by all XENVER_ subops
> >> > except commandline (and build_id in later patch).
> >> > 
> >> > I think both of you are OK with that?
> >> 
> >> Iirc Andrew's request was to honor XSM denies on any sub-op
> >> when a non-default policy is in place. Whereas in default mode
> >> only command line and build id are the ones clearly needing
> >> restricting. Which won't be possible if you ignore the return
> >> value of the XSM check in some of the cases.
> > 
> > That means we need two (as earlier patches had it) version labels.
> > One for the command_line and build_id (version_priv) and one for
> > the rest (version_use). By default version_use would be available
> > to every guest. If a non-default policy wants to mess with it - that is OK.
> 
> That would seem a little too coarse grained. Why can't we keep it
> at the sub-op level, just that the default is "OK" for everything
> except the two?

So you thinking have a whole new XSM 'class' for this hypercall?

As in (not compile tested of course):


> 
> > Now comes the big question - for the XENVER_[version|capabilities|
> > parameters|get_features|page_size|guest_handle] - if it is denied
> > (so non-default version_use policy) - what should we return?
> 
> "<denied>" just like for the others that return strings; page_size
> and other numeric ones may need to return zero.
> 
> > I can return '<denied>' for the strings, but what should we do
> > for the page_size, capabilities and guest_handle ? -EPERM?
> 
> guest_handle is particularly interesting: It seems to make very
> little sense to deny a guest access to its own handle.
> 
> Jan
>

Comments

Jan Beulich Jan. 12, 2016, 4:42 p.m. UTC | #1
>>> On 12.01.16 at 17:37, <konrad.wilk@oracle.com> wrote:
> On Mon, Jan 11, 2016 at 09:17:57AM -0700, Jan Beulich wrote:
>> >>> On 11.01.16 at 17:01, <konrad.wilk@oracle.com> wrote:
>> > On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
>> >> >>> On 08.01.16 at 18:31, <konrad.wilk@oracle.com> wrote:
>> >> >> >> > The rest: XENVER_[version|capabilities|
>> >> >> >> > parameters|get_features|page_size|guest_handle] behave
>> >> >> >> > as before - allowed by default for all guests.
>> >> >> >> > 
>> >> >> >> > This is with the XSM default policy and with the dummy ones.
>> >> >> >> 
>> >> >> >> And with a non-default policy you now ignore one of the latter
>> >> >> >> ops to also get denied.
>> >> >> > 
>> >> >> > No, but that is due to the 'deny' being only checked for certain subops.
>> >> >> 
>> >> >> To me this reply seems contradictory in itself: The "no" doesn't
>> >> >> seem to match up with the rest.
>> >> >> 
>> >> >> > I think what you are saying is that for XENVER_[version|capabilities|
>> >> >> > parameters|get_features|page_size|guest_handle] we should not have any
>> >> >> > XSM checks as they serve no purpose (which is what I had in the earlier
>> >> >> > versions of this patch). However Andrew mentioned that he would
>> >> >> > like _ALL_ of the sub-ops to be checked for.
>> >> >> 
>> >> >> And I agree with Andrew, hence my earlier comment above (with
>> >> >> the reply I can't really make sense of).
>> >> > 
>> >> > I am all confused now.
>> >> > 
>> >> > There are two parts here:
>> >> >  a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle
>> >> >    without any hinderance. For XENVER_commandline and XENVER_buildid
>> >> >    they are evaluated.
>> >> > 
>> >> >  b) Acting on the XSM check. For most of them we cannot actually return
>> >> >    -EFAULT and MUST return either an valid value or some form of a string.
>> >> >    
>> >> >    The ones for which we could return '<denied>' were changeset, 
> compile_info,
>> >> >    commandline, extraversion. To make it simpler we only do it for
>> >> >    commandline.
>> >> > 
>> >> > In essence we have an XSM check which is ignored by all XENVER_ subops
>> >> > except commandline (and build_id in later patch).
>> >> > 
>> >> > I think both of you are OK with that?
>> >> 
>> >> Iirc Andrew's request was to honor XSM denies on any sub-op
>> >> when a non-default policy is in place. Whereas in default mode
>> >> only command line and build id are the ones clearly needing
>> >> restricting. Which won't be possible if you ignore the return
>> >> value of the XSM check in some of the cases.
>> > 
>> > That means we need two (as earlier patches had it) version labels.
>> > One for the command_line and build_id (version_priv) and one for
>> > the rest (version_use). By default version_use would be available
>> > to every guest. If a non-default policy wants to mess with it - that is OK.
>> 
>> That would seem a little too coarse grained. Why can't we keep it
>> at the sub-op level, just that the default is "OK" for everything
>> except the two?
> 
> So you thinking have a whole new XSM 'class' for this hypercall?

Yes, subject to Daniel's input it seems to me that's the only way
providing the necessary granularity.

Jan

Patch
diff mbox

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 17f304e..fca5809 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -141,6 +141,13 @@  if (guest_writeconsole) {
 # pmu_ctrl is for)
 allow domain_type xen_t:xen2 pmu_use;
 
+allow dom0_t version:domain {
+    version parameters ... commandline build_id
+};
+allow domain_type version:domain {
+    version parameters ...
+}
+
 ###############################################################################
 #
 # Domain creation
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c123256..4b20d08 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -246,6 +246,18 @@  class domain2
     psr_cat_op
 }
 
+# defined by XENVER_hypercall
+class xenver
+{
+# XENVER_version
+    version
+# XENVER_parameters
+    parameters
+# ... snip..
+    commandline
+    build_id
+}
+
 # Similar to class domain, but primarily contains domctls related to HVM domains
 class hvm
 {