| Message ID | 20160112163712.GB17685@char.us.oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> 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
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 {