Re: [Xen-devel] [PATCH v3 11/15] xsm, argo: XSM control for argo register
> From: Christopher Clark > Subject: [PATCH v3 11/15] xsm, argo: XSM control for argo register > > XSM controls for argo ring registration with two distinct cases, where > the ring being registered is: > > 1) Single source: registering a ring for communication to receive messages >from a specified single other domain. >Default policy: allow. > > 2) Any source: registering a ring for communication to receive messages >from any, or all, other domains (ie. wildcard). >Default policy: deny, with runtime policy configuration via bootparam. > > The existing argo-mac boot parameter indicates administrator preference for > either permissive or strict access control, which will allow or deny > registration of any-sender rings. > > This commit modifies the signature of core XSM hook functions in order to > apply 'const' to arguments, needed in order for 'const' to be accepted in > signature of functions that invoke them. > > Signed-off-by: Christopher Clark Acked-by: Daniel De Graaf While it does not need to be a part of this patch, somewhere in the series you should add a rule allowing these features to be used by guests in the default XSM policy; tools/flask/policy/modules/guest_features.te is where features like this have previously been handled. Since you're adding permissions one at a time, you could add the rules all at once or as a part of the patch adding the vector. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 14/15] xsm, argo: notify: don't describe rings that cannot be sent to
> From: Christopher Clark > Subject: [PATCH v3 14/15] xsm, argo: notify: don't describe rings that cannot > be sent to > > Signed-off-by: Christopher Clark I have not checked to see how commonly this function is called, but it looks like it may have the potential for producing excessive AVC denials when just checking. If this is the case, using another XSM hook (or adding a bool parameter to the existing one) to distinguish between this case and the actual send attempt would let you use avc_has_perm_noaudit here to avoid that log spam. If this call doesn't happen in some automated/common fashion, it's fine as-is. Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/15] xsm, argo: XSM control for argo message send operation
> From: Christopher Clark > Subject: [PATCH v3 12/15] xsm, argo: XSM control for argo message send > operation > > Default policy: allow. > > Signed-off-by: Christopher Clark Acked-by: Daniel De Graaf Comment to #11 applies here (adding an AVC vector, should also change default policy). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 13/15] xsm, argo: XSM control for any access to argo by a domain
> From: Christopher Clark > Subject: [PATCH v3 13/15] xsm, argo: XSM control for any access to argo by a > domain > > Will inhibit initialization of the domain's argo data structure to > prevent receiving any messages or notifications and access to any of > the argo hypercall operations. > > Signed-off-by: Christopher Clark Acked-by: Daniel De Graaf Comment to #11 applies here (adding an AVC vector, should also change default policy). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 4/4] xen/xsm: Remove printing from set_to_dummy_if_null()
> From: Xin Li > > Filling dummy module's hook to null value of xsm_operations structure > will generate debug message. This becomes boot time spew for module > like silo, which only sets a few hooks of itself. So remove the printing > to avoid boot time spew. > > Signed-off-by: Xin Li Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/5] x86/domctl: Implement XEN_DOMCTL_get_cpu_policy
> From: Sergey Dyasli > > This finally (after literally years of work!) marks the point where the > toolstack can ask the hypervisor for the current CPUID configuration of a > specific domain. > > Introduce a new flask access vector and update the default policies. > > Also extend xen-cpuid's --policy mode to be able to take a domid and dump a > specific domains CPUID and MSR policy. > > Signed-off-by: Andrew Cooper > Signed-off-by: Sergey Dyasli Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/5] x86/sysctl: Implement XEN_SYSCTL_get_cpu_policy
> From: Sergey Dyasli
>
> Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
> policy information.
>
> For the flask side of things, this subop is closely related to
> {phys,cputopo,numa}info, so shares the physinfo access vector.
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: Re: Flask default policy mismatch vs dummy
> -Original Message-
> From: Jan Beulich
> Sent: Friday, October 26, 2018 7:16 AM
> To: Daniel de Graaf
> Cc: Andrew Cooper ; xen-de...@lists.xen.org
> Subject: [Non-DoD Source] Ping: Re: Flask default policy mismatch vs dummy
>
> >>> On 11.10.18 at 13:40, wrote:
> On 11.10.18 at 10:05, wrote:
> >> Found while looking at some OSSTest logs.
> >>
> >> Oct 9 14:03:09.579037 (XEN) avc: denied { setup } for domid=0
> >> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
> >> tclass=resource
> >> Oct 9 14:03:09.590863 [0.522193] Failed to report MMCONFIG reservation
> >> state for PCI MMCONFIG [bus 00-7f] to hypervisor (-13)
> >>
> >> If someone has some tuits, please feel free. If not, I'll see what I
> >> can do when I've got some time.
> >
> > How about this?
> >
> > Jan
>
> Daniel, do you have any thoughts here?
>
> Thanks, Jan
This looks like a missing allow rule in the policy for dom0; something like:
allow dom0_t xen_t: resource setup;
in dom0.te at the end near the admin_device() statements. I'm not at my Linux
system at the moment, otherwise I'd make a patch.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask: Add check for io{port, mem}con sorting
> From: Jan Beulich > >>> On 28.09.18 at 21:13, wrote: > > These entries are not always sorted by checkpolicy. Enforce the sorting > > (which can be done manually if using an unpatched checkpolicy) when > > loading the policy so that later uses by the security server do not > > incorrectly use the initial sid. > > "Enforce the sorting" could mean two things - sorting what's unsorted, > or (as you do) raise an error. Isn't raising an error here possibly going > to impact systems which currently work? > > Jan A system whose iomemcon entries are unsorted is currently not enforcing the intended security policy. It normally ends up enforcing a more restrictive policy, but not always (it depends on what you allow access to the default label). My guess is that anyone impacted by this problem would have noticed when they added the rule and it had no effect. However, I do agree this could cause an error on currently-working systems that do things like add iomemcon entries that they don't use. Are you suggesting an update to the commit message to make this breakage clear, or does the problem need to be fixed in the hypervisor? It would be possible to sort the entries as they're added, but that's not as easy as just detecting the mis-sort (since they're a linked list), and the policy creation process should have already sorted them (except that that part was missing). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Non-DoD Source] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
> > When SILO is enabled, there would be no page-sharing or event notifications > between unprivileged VMs (no grant tables or event channels). > > Signed-off-by: Xin Li > Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Non-DoD Source] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm
> > Introduce new boot parameter xsm to choose which xsm module is enabled, > and set default to dummy. > > Signed-off-by: Xin Li Acked-by: Daniel De Graaf It might be useful for the commit message to also reference the new Kconfig option; thanks for adding it. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Non-DoD Source] [PATCH] xsm: fix clang build
> -Original Message- > From: Roger Pau Monne > Sent: Wednesday, September 5, 2018 10:46 AM > To: xen-devel@lists.xenproject.org > Cc: Roger Pau Monne ; Daniel De Graaf > > Subject: [Non-DoD Source] [PATCH] xsm: fix clang build > > ebitmap.c:244:32: error: invalid conversion specifier 'Z' > [-Werror,-Wformat-invalid-specifier] >"match my size %Zd (high bit was %d)\n", mapunit, > ~^ > ebitmap.c:245:16: error: format specifies type 'int' but the argument has > type 'unsigned long' > [-Werror,-Wformat] >sizeof(u64) * 8, e->highbit); >^~~ > ebitmap.c:245:33: error: data argument not used by format string > [-Werror,-Wformat-extra-args] >sizeof(u64) * 8, e->highbit); > > Use %zd instead of %Zd, which is compliant with C99. > > Signed-off-by: Roger Pau Monné Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Non-DoD Source] [PATCH 4/5] xen/domain: Fold xsm_free_security_domain() paths together
> From: Andrew Cooper > Sent: Monday, September 3, 2018 10:47 AM > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Wei Liu ; Roger Pau > Monné ; Stefano Stabellini ; > Julien Grall ; Daniel De Graaf > > Subject: [Non-DoD Source] [PATCH 4/5] xen/domain: Fold > xsm_free_security_domain() paths together > > xsm_free_security_domain() is idempotent (both the dummy handler, and the > flask handler). Move it into the shared __domain_destroy() path, and drop the > INIT_xsm flag from domain_create() > > Signed-off-by: Andrew Cooper Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 6/6] xsm: add tee access policy support
> From: Volodymyr Babchuk > Sent: Wednesday, August 22, 2018 10:12 AM > > As we don't want any guest to access limited resources of TEE, we need a way > to control who can work with it. > > Thus, new access vector class "tee" is added with only ony operation "call" > so far. tee framework uses this to check if guest has a right > to work with TEE. > > Also, example security context domU_with_tee_t was added. > > Signed-off-by: Volodymyr Babchuk Are you planning to add more access vectors to this class in the future? Otherwise, it probably doesn't need its own class - since you use xen_t as the target, placing it in class xen/xen2 is preferred (like tmem and others are now). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM
-Original Message- > On 13/06/18 23:15, Stefano Stabellini wrote: > > This is very useful when starting multiple domains from Xen without > > xenstore access. It will allow them to print out to the Xen console. > > > > Signed-off-by: Stefano Stabellini > > CC: andrew.coop...@citrix.com > > CC: george.dun...@eu.citrix.com > > CC: ian.jack...@eu.citrix.com > > CC: jbeul...@suse.com > > CC: konrad.w...@oracle.com > > CC: t...@xen.org > > CC: wei.l...@citrix.com > > CC: dgde...@tycho.nsa.gov > > --- > > If there is a better way to do this with XSM, please advise. > > We definitely need to keep the XSM around to avoid opening a hole. We also > don't want all the domain to access the console. > > Looking at the implementation, any domain with is_privileged will be able to > access the console. IHMO, I don't think we should set > that for DomU created by Xen. > > So I would suggest to introduce a new variable is_console and to tell whether > a domain can access the console. xsm_console_io(...) > would then need to be updated accordingly. There is an existing CONFIG_VERBOSE_DEBUG option which, among other things, allows console output from any domain. The console output part of that (which is just the #ifdef in include/xsm/dummy.h) could be moved to another CONFIG or ORed with an ARM flag. This would apply to all domains; if that's not what you want, you'll need to add a flag (like Julien suggested) or use XSM. If XSM is enabled, guest hypervisor console output is controlled by the guest_writeconsole boolean in the default policy (tools/flask/policy/modules/guest_features.te) which defaults to allowing it. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
