Based on the AVC, the /etc/machine-id is mislabeled. The correct context is:

# matchpathcon /etc/machine-id 
/etc/machine-id	system_u:object_r:machineid_t:s0

Please run following command, which fixes the context:

# restorecon -v /etc/machineid

It's weird this is mislabeled because it's a fresh install.

# ls -lZ /etc/machine-id
-rw-r--r--. root root system_u:object_r:var_run_t:s0   /etc/machine-id

# restorecon -v /etc/machine-id
restorecon reset /etc/machine-id context system_u:object_r:var_run_t:s0->system_u:object_r:machineid_t:s0
restorecon set context /etc/machine-id->system_u:object_r:machineid_t:s0 failed:'Read-only file system'

# mount | egrep '(vda1|machine-id)'
/dev/vda1 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
tmpfs on /etc/machine-id type tmpfs (ro,relatime,seclabel,mode=755)

# /usr/sbin/fixfiles -f relabel
Cleaning out /tmp
Warning: Skipping the following R/O filesystems:
/etc/machine-id
Warning: Skipping the following R/O filesystems:
/etc/machine-id
Relabeling / /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /run /sys /sys/fs/cgroup
100.0%
Cleaning up labels on /tmp

# ls -lZ /etc/machine-id
-rw-r--r--. root root system_u:object_r:var_run_t:s0   /etc/machine-id

After a reboot, systemd seems to have fixed it:

# ls -lZ /etc/machine-id
-rw-r--r--. root root system_u:object_r:machineid_t:s0 /etc/machine-id


I don't know if this is a general issue or not though.

The other part of this bug report concerns rsyslog not being allowed to connect to the central logging service. I cannot find a boolean/label that would permit that. Could it be considered an enhancement to the rsyslog's SELinux policy?

Are there any SELinux denials?

# ausearch -m avc -m user_avc -m selinux_err -i -ts today

Excluding the machine-id ones, I see only this:

type=AVC msg=audit(06/15/2015 14:02:29.025:4368) : avc:  denied  { name_connect } for  pid=17276 comm=rs:main Q:Reg dest=2514 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket 

I've configured rsyslog to connect to a central logging server.

Based on the rsyslog.conf man page, the 2514 port seems to be a default port for RELP, therefore we need to add it to the list SELinux port definitions:

# seinfo --portcon | grep 514
	portcon tcp 5149 system_u:object_r:cluster_port_t:s0
	portcon udp 5149 system_u:object_r:cluster_port_t:s0
	portcon tcp 514 system_u:object_r:rsh_port_t:s0
	portcon udp 514 system_u:object_r:syslogd_port_t:s0
	portcon tcp 6514 system_u:object_r:syslog_tls_port_t:s0
	portcon udp 6514 system_u:object_r:syslog_tls_port_t:s0
	portcon tcp 16514 system_u:object_r:virt_port_t:s0
	portcon udp 16514 system_u:object_r:virt_port_t:s0
#

(In reply to Milos Malik from comment #7)
> Based on the rsyslog.conf man page, the 2514 port seems to be a default port
> for RELP, therefore we need to add it to the list SELinux port definitions:

Please don't.

Quoting the man page:

> If you would like to prevent message loss, use RELP:
>        *.* :omrelp:192.168.0.1:2514
>
> Note that a port number was given as there is no standard port for relp.

There indeed is no standard port and we shouldn't add any to the default policy.

I believe machine-id issue has been fixed in RHEL7.2 with filename transition rules.

Milos,
are you able to reproduce it with a fresh isntall?

As Tomas pointed in c8 out. The port 2514 is not a standard port, it was randomly chosen for example purposes in the documentation. From this point of view this is not a bug and could be closed.

The correct approach, and I use it in my tests, should be:
# semanage port -m -t syslogd_port_t -p tcp 2514
# service rsyslog start

That makes sense. Since systemd fixed itself after a reboot and it's reported to be fixed in RHEL7.2 and this is not actually a standard port. For what's worth, I agree this could be closed. Thank you all.