Does it start if you enable selinux first, for example by running setenforce 0 ?

(In reply to Michael Young from comment #1)
> Does it start if you enable selinux first, for example by running setenforce
> 0 ?

Yes:


[root@tst063 ~]# setenforce 0
[root@tst063 ~]# systemctl start  xenconsoled.service
[root@tst063 ~]# systemctl status  xenconsoled.service
● xenconsoled.service - Xenconsoled - handles logging from guest consoles and hypervisor
   Loaded: loaded (/usr/lib/systemd/system/xenconsoled.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2017-08-24 10:38:38 EDT; 5s ago
  Process: 2051 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR} (code=exited, status=0/SUCCESS)
  Process: 2050 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 2052 (xenconsoled)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/xenconsoled.service
           └─2052 /usr/sbin/xenconsoled -i --log=none --log-dir=/var/log/xen/console

Just to confirm, when you said 'enable' you meant 'disable' - as setenforce 0 disables SELinux.

Sooo ..what is the next step? Should this be re-assigned to selinux package?

Proposed as a Blocker for 27-final by Fedora user konradr using the blocker tracking app because:

 Fails QA:Testcase_Boot_Methods_Xen_Para_Virt

Next step is, re-assign to selinux-policy-targeted , and include the details of the denials. Best way to do that is to run the test with SELinux in Permissive mode, then run:

ausearch -m avc -ts recent

that should find all the relevant denials and you can paste them into the bug...

Discussed during blocker review [1]:

punt (delay decision) - it's not clear whether this actually violates the criterion, so we will request a more detailed explanation from Konrad

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-04/

Konrad, can you please explain what exactly is broken here? What consequences does it have? Also, please look at https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Xen_DomU and tell us whether you consider the criterion violated as currently written. Thanks.

(In reply to Adam Williamson from comment #6)
> Next step is, re-assign to selinux-policy-targeted , and include the details
> of the denials. Best way to do that is to run the test with SELinux in
> Permissive mode, then run:
> 
> ausearch -m avc -ts recent
> 
> that should find all the relevant denials and you can paste them into the
> bug...

# ausearch -m avc -ts recent
----
time->Mon Sep  4 20:30:55 2017
type=AVC msg=audit(1504571455.230:108): avc:  denied  { map } for  pid=830 comm="abrt-dump-journ" path="/var/lib/sss/mc/passwd" dev="dm-1" ino=17742853 scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file permissive=1
----
time->Mon Sep  4 20:30:55 2017
type=AVC msg=audit(1504571455.282:110): avc:  denied  { sys_resource } for  pid=831 comm="xenconsoled" capability=24  scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:system_r:xenconsoled_t:s0 tclass=capability permissive=1
----
time->Mon Sep  4 20:30:55 2017
type=AVC msg=audit(1504571455.282:111): avc:  denied  { getattr } for  pid=831 comm="xenconsoled" path="/run/xenstored/socket" dev="tmpfs" ino=24187 scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
----
time->Mon Sep  4 20:30:55 2017
type=AVC msg=audit(1504571455.282:112): avc:  denied  { write } for  pid=831 comm="xenconsoled" name="socket" dev="tmpfs" ino=24187 scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
----
time->Mon Sep  4 20:30:59 2017
type=AVC msg=audit(1504571459.025:136): avc:  denied  { remount } for  pid=917 comm="(ostnamed)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:xenstored_var_lib_t:s0 tclass=filesystem permissive=1

(In reply to Kamil Páral from comment #7)
> Discussed during blocker review [1]:
> 
> punt (delay decision) - it's not clear whether this actually violates the
> criterion, so we will request a more detailed explanation from Konrad
> 
> [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-04/
> 
> Konrad, can you please explain what exactly is broken here? What
> consequences does it have? Also, please look at
> https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Xen_DomU and
> tell us whether you consider the criterion violated as currently written.
> Thanks.

Sure thing. The xenconsoled service is used to get console support for guests.

That is this runs inside of Xen dom0. And from reading the URLs (and the discussion from 2011) it does not hit the criteria (sorry about that, my memory was wrong). Removing the blocker part.

A bit of explanation - I had in mind the "..supported Xen Dom0", but that actually means: " ..  it needs to run with a previous release as Dom0" (as in Fedora Core 26). [https://lists.fedoraproject.org/pipermail/test/2011-October/103678.html]

Which seems really weird - as if this does not get fixed in F27 (as dom0), then F28 (guest) won't be able to run as guest anymore with the previous release of F27.

...
> A bit of explanation - I had in mind the "..supported Xen Dom0", but that
> actually means: " ..  it needs to run with a previous release as Dom0" (as
> in Fedora Core 26).
> [https://lists.fedoraproject.org/pipermail/test/2011-October/103678.html]

Just to be sure: 

.. which would mean if I test the rawhide guests under F26 ("supported Xen Dom0") and there are issues booting rawhide guests (b/c of issues in F26) then it would still be a blocker against rawhide for the packages that have issues in F26 (if naturally the issues are also present in rawhide?).

That's, uhh...hmm. A bit of a grey area. The basic point of the criterion was to block on domU functionality not dom0, as I understand it, so having F27 blocked on a 'fix' to F26 dom0 seems a bit odd.

Created attachment 1322208 [details]
search -m avc -ts recent" under F26

(In reply to Adam Williamson from comment #11)
> That's, uhh...hmm. A bit of a grey area. The basic point of the criterion
> was to block on domU functionality not dom0, as I understand it, so having
> F27 blocked on a 'fix' to F26 dom0 seems a bit odd.

Hehe. Anyhow just in case that is how you folks want to interpret it that way, I am attaching the output from running "ausearch -m avc -ts recent" under F26 as dom0 (which also has similar SELinux issues, but many more which got fixed in F26 time-frame).

On F27 I can get xenconsoled to start on boot in enforcing mode if I do
semanage fcontext -a -t xen_device_t /dev/xen/xenbus
on a previous boot.

If I also set 
allow xenconsoled_t self:capability { sys_resource sys_tty_config };
allow xenconsoled_t self:unix_dgram_socket create;
allow xenconsoled_t var_run_t:sock_file getattr;
allow xenconsoled_t xen_device_t:chr_file map;
in a module I can use xenconsoled to get a console on a xen guest

The relevant entries in the audit.log are

type=AVC msg=audit(1504637347.487:279): avc:  denied  { map } for  pid=857 comm="xenconsoled" path="/dev/xen/gntdev" dev="devtmpfs" ino=11516 scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:object_r:xen_device_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1504637347.487:280): avc:  denied  { map } for  pid=857 comm="xenconsoled" path="/dev/xen/privcmd" dev="devtmpfs" ino=16289 scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:object_r:xen_device_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1504637758.588:295): avc:  denied  { sys_resource } for  pid=3050 comm="xenconsoled" capability=24  scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:system_r:xenconsoled_t:s0 tclass=capability permissive=0
type=AVC msg=audit(1504637758.588:296): avc:  denied  { create } for  pid=3050 comm="xenconsoled" scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:system_r:xenconsoled_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1504637758.589:297): avc:  denied  { sys_tty_config } for  pid=3050 comm="xenconsoled" capability=26  scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:system_r:xenconsoled_t:s0 tclass=capability permissive=0
type=AVC msg=audit(1504637758.589:298): avc:  denied  { getattr } for  pid=3050 comm="xenconsoled" path="/run/xenstored/socket" dev="tmpfs" ino=23282 scontext=system_u:system_r:xenconsoled_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0

Still an issue with Fedora-Server-dvd-x86_64-27-20170912.n.0.iso

And with https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20170922.0/compose/Server/x86_64/iso/Fedora-Server-dvd-x86_64-27_Beta-1.2.iso

Still an issue with Fedora-Server-dvd-x86_64-27_Beta-1.3.iso

Patches for this posted on:

http://oss.tresys.com/pipermail/refpolicy/2017-October/010133.html
and
http://oss.tresys.com/pipermail/refpolicy/2017-October/010134.html

And pull request for Fedora's selinux-policy initiated as well:

https://github.com/fedora-selinux/selinux-policy/pull/204