[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote: > >>> On 08.01.16 at 18:31, <konrad.wilk@xxxxxxxxxx> 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. 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? I can return '<denied>' for the strings, but what should we do for the page_size, capabilities and guest_handle ? -EPERM? Or leave those out of the version_use check? (so do not act on XSM check on those?) > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |