On Mon, Jun 06, 2016 at 05:41:35PM +0100, George Dunlap wrote: > Hey Michael, CC-ing Olif and Daniel De Graaf, > > Not sure if you know, I've been maintaining the Xen4CentOS packages; I > suspect given the similarities between our systems we're solving the > same issues; particularly with the systemd/selinux combination. > > I've just ported my patchqueue up to 4.7-rc4, and it looks like the > SELinux rules for xenstored -- at least the ones that come with CentOS > 7 -- are outdated; they allow xenstored to open /proc/xen/privcmd > (which is deprecated), but not /dev/xen/privcmd. > > Do you know where the "upstream" for these rules are, and how to get > them changed in a way that will trickle down eventually to CentOS? You open a bug against selinux policies. For example see: https://bugzilla.redhat.com/show_bug.cgi?id=1322625 https://bugzilla.redhat.com/show_bug.cgi?id=1334511 And (which is exactly what you are hitting): Bug 1334115 - SELinux is preventing xenconsoled from 'ioctl' accesses on the chr_file /dev/xen/privcmd. (edit) Since not all of them went in F24 one way you can work around this is to have a new 'xen-tools-selinux' package that will install the new SELinux policies. However I have to confess I hadn't managed to fix the /dev/xen/privcmd. It still pops up occasionaly. The fix 1334115 is: dev/xen/blktap.* -c gen_context(system_u:object_r:xen_device_t,s0) /dev/xen/evtchn -c gen_context(system_u:object_r:xen_device_t,s0) /dev/xen/gntdev -c gen_context(system_u:object_r:xen_device_t,s0) /dev/xen/gntalloc -c gen_context(system_u:object_r:xen_device_t,s0) +/dev/xen/privcmd -c gen_context(system_u:object_r:xen_device_t,s0) Which I tried to replicate (see xen.fc) For OL7 I did: semanage fcontext -a -t xen_device_t /dev/xen/privcmd restorecon -Rv /dev/xen/privcmd in the %post section of the spec file. However oddly enough it does not always work and I am not sure what is up with that. Also for OL7 I needed to do a bunch of other policies (see attached) to get all of them SELinux complains out. This is what I did in the %build: %if 0%{?el7} make -f /usr/share/selinux/devel/Makefile xenstored_policy.pp make -f /usr/share/selinux/devel/Makefile xenconsoled_policy.pp make -f /usr/share/selinux/devel/Makefile xen.fc %endif and in %install: %global modulenames xenstored_policy xenconsoled_policy # Usage: _format var format # Expand 'modulenames' into various formats as needed # Format must contain '$x' somewhere to do anything useful %global _format() export %1=""; for x in %{modulenames}; do %1+=%2; %1+=" "; done; %_format MODULES $x.pp install -d %{buildroot}%{_datadir}/selinux/packages install -m 0644 $MODULES %{buildroot}%{_datadir}/selinux/packages install -m 0644 xen.fc %{buildroot}%{_datadir}/selinux/packages And in the %post: %post tools-selinux %_format MODULES %{_datadir}/selinux/packages/$x.pp %{_sbindir}/semodule -s %{selinuxtype} -i $MODULES %{_sbindir}/semanage fcontext -a -t xen_device_t /dev/xen/privcmd if %{_sbindir}/selinuxenabled ; then %{_sbindir}/load_policy %{_sbindir}/restorecon -Rv /dev/xen/privcmd fi %endif CC-ing Olif. > > As of 4.7-rc4, libxc will first try to open /dev/xen/privcmd, then > *if* it fails with a certain set of error codes, it tries > /proc/xen/privcmd instead. Unfortunately, EACCES (the failure you get > from SELinux denials) is not one of those error codes. If you just > add that error code in to the list of acceptable error codes, then > things work for me. > > Thanks, > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel