selinux denials when starting docker in F23

[Dusty Mabe]

Hey guys anybody seen these when starting 
docker-1.8.2-5.gitcb216be.fc23.x86_64:

```
Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc:  denied { 
read } for  pid=1513 comm="iptables" path="net:[4026531957]" dev="nsfs" 
ino=4026531957 scontext=system_u:system_r:iptables_t:s0 
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
```

Nevertheless the docker daemon is up and running but if I start a 
container and then force remove it I see:

```
Error deleting container: Error response from daemon: Cannot destroy 
container 
710f834e316946a422a00fb3470b895b387519ecb01a5b195cc818b9764f82a7: Failed 
to set container state to RemovalInProgress: Status is already 
RemovalInProgress
```

and this is in the journal:

```
Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='Unknown permission stop for class system 
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='Unknown permission stop for class system 
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
```

[Dusty Mabe]

On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> Hey guys anybody seen these when starting
> docker-1.8.2-5.gitcb216be.fc23.x86_64:
> Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc: denied {
> read } for  pid=1513 comm="iptables" path="net:[4026531957]"
> dev="nsfs" ino=4026531957 scontext=system_u:system_r:iptables_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
>
> Nevertheless the docker daemon is up and running but if I start a
> container and then force remove it I see:
> Error deleting container: Error response from daemon: Cannot destroy
> container
> 710f834e316946a422a00fb3470b895b387519ecb01a5b195cc818b9764f82a7:
> Failed to set container state to RemovalInProgress: Status is already
> RemovalInProgress
>
> and this is in the journal:
> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='Unknown permission stop for class system
> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='Unknown permission stop for class system
> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Also (on a separate machine - this time the f23 cloud vagrant box) - I 
am seeing this when I run `docker run -it --rm busybox /bin/sh`:

```
[root@f23 ~]# docker run -it --rm busybox /bin/sh
permission denied
Error response from daemon: Cannot start container 
48f491260754d82c292f0d52154cb9fc45f8dede1a9bdc9adbe9a465406671e5: [8] 
System error: permission denied
```

and from the journal:

```
Oct 08 19:19:01 f23 audit[998]: AVC avc:  denied  { transition } for 
pid=998 comm="exe" path="/bin/sh" dev="dm-3" ino=33555457 
scontext=system_u:system_r:unconfined_service_t:s0 
tcontext=system_u:system_r:svirt_lxc_net_t:s0:c581,c843 tclass=process 
permissive=0
```

[Daniel J Walsh]

On 10/08/2015 03:23 PM, Dusty Mabe wrote:
> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> > Hey guys anybody seen these when starting
> > docker-1.8.2-5.gitcb216be.fc23.x86_64:
> > Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc: denied {
> > read } for  pid=1513 comm="iptables" path="net:[4026531957]"
> > dev="nsfs" ino=4026531957 scontext=system_u:system_r:iptables_t:s0
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
> >
> > Nevertheless the docker daemon is up and running but if I start a
> > container and then force remove it I see:
> > Error deleting container: Error response from daemon: Cannot destroy
> > container
> > 710f834e316946a422a00fb3470b895b387519ecb01a5b195cc818b9764f82a7:
> > Failed to set container state to RemovalInProgress: Status is already
> > RemovalInProgress
> >
> > and this is in the journal:
> > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > msg='Unknown permission stop for class system
> > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > msg='Unknown permission stop for class system
> > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>
> Also (on a separate machine - this time the f23 cloud vagrant box) - I
> am seeing this when I run `docker run -it --rm busybox /bin/sh`:
> [root@f23 ~]# docker run -it --rm busybox /bin/sh
> permission denied
> Error response from daemon: Cannot start container
> 48f491260754d82c292f0d52154cb9fc45f8dede1a9bdc9adbe9a465406671e5: [8]
> System error: permission denied
>
> and from the journal:
> Oct 08 19:19:01 f23 audit[998]: AVC avc:  denied  { transition } for
> pid=998 comm="exe" path="/bin/sh" dev="dm-3" ino=33555457
> scontext=system_u:system_r:unconfined_service_t:s0
> tcontext=system_u:system_r:svirt_lxc_net_t:s0:c581,c843 tclass=process
> permissive=0
>
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

This looks like docker is running with the wrong context.  Make sure
docker-selinux is installed. and /usr/bin/docker has the right label.

restorecon -v /usr/bin/docker

If docker is still labeled bin_t, then check if docker.pp is installed

semodule -l | grep docker

If you don't see docker listed, check if docker-selinux is installed.

yum install docker-selinux

If docker label changes you need to restart the docker daemon

systemctl restart docker
ps -eZ | grep docker

Should be running as docker_t

There could be a conflict between selinux-policy and docker-selinux, I
think selinux-policy has dropped docker.pp from its list of policy
packages, which it should do.
docker-selinux is now supposed to ship it.   But it could be
docker-selinux is installed and then selinux-policy gets updated and
removes the docker.pp file.

Just speculating on what could cause this.

[Dusty Mabe]

On 10/09/2015 06:12 AM, Daniel J Walsh wrote:
> This looks like docker is running with the wrong context.  Make sure
> docker-selinux is installed. and /usr/bin/docker has the right label.
>
> restorecon -v /usr/bin/docker
>
> If docker is still labeled bin_t, then check if docker.pp is installed
>
> semodule -l | grep docker
>
> If you don't see docker listed, check if docker-selinux is installed.
>
> yum install docker-selinux
>
> If docker label changes you need to restart the docker daemon
>
> systemctl restart docker
> ps -eZ | grep docker
>
> Should be running as docker_t
>
> There could be a conflict between selinux-policy and docker-selinux, I
> think selinux-policy has dropped docker.pp from its list of policy
> packages, which it should do.
> docker-selinux is now supposed to ship it.   But it could be
> docker-selinux is installed and then selinux-policy gets updated and
> removes the docker.pp file.
>
> Just speculating on what could cause this.

It's odd. If I start fresh with an 'older' F23 cloud image I never see 
docker.pp installed:

```
[root@f23 ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.13.1-144.fc23.noarch
[root@f23 ~]# semodule -l | grep docker
[root@f23 ~]# dnf install -y docker &> /dev/null
[root@f23 ~]# rpm -q docker-selinux
docker-selinux-1.8.2-5.gitcb216be.fc23.x86_64
[root@f23 ~]# semodule -l | grep docker
[root@f23 ~]# ls -lZ /usr/bin/docker
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 20707376 Sep 21 20:21 
/usr/bin/docker
[root@f23 ~]# dnf update selinux-policy-targeted -y &> /dev/null
[root@f23 ~]# semodule -l | grep docker
[root@f23 ~]#
```

If I start with a slightly newer F23 cloud image I see:

```
[root@footest ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.13.1-147.fc23.noarch
[root@footest ~]# semodule -l | grep docker
[root@footest ~]# dnf install -y docker &> /dev/null
[root@footest ~]# rpm -q docker-selinux
docker-selinux-1.8.2-5.gitcb216be.fc23.x86_64
[root@footest ~]# semodule -l | grep docker
docker
[root@footest ~]# ls -lZ /usr/bin/docker
-rwxr-xr-x. 1 root root system_u:object_r:docker_exec_t:s0 20707376 Sep 
21 20:21 /usr/bin/docker
[root@footest ~]# dnf update selinux-policy-targeted -y
Last metadata expiration check performed 0:04:49 ago on Fri Oct  9 
15:40:48 2015.
Dependencies resolved.
Nothing to do.
Complete!
```

So.. Is there a bug here? Seems like it.

Dusty

[Dusty Mabe]

On 10/09/2015 11:46 AM, Dusty Mabe wrote:
> On 10/09/2015 06:12 AM, Daniel J Walsh wrote:
> > This looks like docker is running with the wrong context.  Make sure
> > docker-selinux is installed. and /usr/bin/docker has the right label.
> >
> > restorecon -v /usr/bin/docker
> >
> > If docker is still labeled bin_t, then check if docker.pp is installed
> >
> > semodule -l | grep docker
> >
> > If you don't see docker listed, check if docker-selinux is installed.
> >
> > yum install docker-selinux
> >
> > If docker label changes you need to restart the docker daemon
> >
> > systemctl restart docker
> > ps -eZ | grep docker
> >
> > Should be running as docker_t
> >
> > There could be a conflict between selinux-policy and docker-selinux, I
> > think selinux-policy has dropped docker.pp from its list of policy
> > packages, which it should do.
> > docker-selinux is now supposed to ship it.   But it could be
> > docker-selinux is installed and then selinux-policy gets updated and
> > removes the docker.pp file.
> >
> > Just speculating on what could cause this.
>
> It's odd. If I start fresh with an 'older' F23 cloud image I never see 
> docker.pp installed:
> [root@f23 ~]# rpm -q selinux-policy-targeted
> selinux-policy-targeted-3.13.1-144.fc23.noarch
> [root@f23 ~]# semodule -l | grep docker
> [root@f23 ~]# dnf install -y docker &> /dev/null
> [root@f23 ~]# rpm -q docker-selinux
> docker-selinux-1.8.2-5.gitcb216be.fc23.x86_64
> [root@f23 ~]# semodule -l | grep docker
> [root@f23 ~]# ls -lZ /usr/bin/docker
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 20707376 Sep 21 
> 20:21 /usr/bin/docker
> [root@f23 ~]# dnf update selinux-policy-targeted -y &> /dev/null
> [root@f23 ~]# semodule -l | grep docker
> [root@f23 ~]#
>
> If I start with a slightly newer F23 cloud image I see:
> [root@footest ~]# rpm -q selinux-policy-targeted
> selinux-policy-targeted-3.13.1-147.fc23.noarch
> [root@footest ~]# semodule -l | grep docker
> [root@footest ~]# dnf install -y docker &> /dev/null
> [root@footest ~]# rpm -q docker-selinux
> docker-selinux-1.8.2-5.gitcb216be.fc23.x86_64
> [root@footest ~]# semodule -l | grep docker
> docker
> [root@footest ~]# ls -lZ /usr/bin/docker
> -rwxr-xr-x. 1 root root system_u:object_r:docker_exec_t:s0 20707376 
> Sep 21 20:21 /usr/bin/docker
> [root@footest ~]# dnf update selinux-policy-targeted -y
> Last metadata expiration check performed 0:04:49 ago on Fri Oct  9 
> 15:40:48 2015.
> Dependencies resolved.
> Nothing to do.
> Complete!
>
> So.. Is there a bug here? Seems like it.

I opened this bug.. https://bugzilla.redhat.com/show_bug.cgi?id=1270521

Dusty

[Matthew Miller]

On Thu, Oct 08, 2015 at 03:06:09PM -0400, Dusty Mabe wrote:
> Hey guys anybody seen these when starting
> docker-1.8.2-5.gitcb216be.fc23.x86_64:

Uh oh. File that as a freeze exception bug, quick?

[Jan Pazdziora]

On Thu, Oct 08, 2015 at 03:06:09PM -0400, Dusty Mabe wrote:
> Hey guys anybody seen these when starting
> docker-1.8.2-5.gitcb216be.fc23.x86_64:
> Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc:  denied { read }
> for  pid=1513 comm="iptables" path="net:[4026531957]" dev="nsfs"
> ino=4026531957 scontext=system_u:system_r:iptables_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0

It's already present on Fedora 22:

https://bugzilla.redhat.com/show_bug.cgi?id=1266391

[Dusty Mabe]

On 10/09/2015 05:56 AM, Jan Pazdziora wrote:
> On Thu, Oct 08, 2015 at 03:06:09PM -0400, Dusty Mabe wrote:
> > Hey guys anybody seen these when starting
> > docker-1.8.2-5.gitcb216be.fc23.x86_64:
> > Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc:  denied { read }
> > for  pid=1513 comm="iptables" path="net:[4026531957]" dev="nsfs"
> > ino=4026531957 scontext=system_u:system_r:iptables_t:s0
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
>
> It's already present on Fedora 22:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1266391

Thanks! I guess I just didn't notice it before. Is there any idea on the 
issue as to what needs to be done for a fix?

Dusty

[Dusty Mabe]

On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> and this is in the journal:
> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
> msg='Unknown permission stop for class system 
> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
> msg='Unknown permission stop for class system 
> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Any comments on the USER_AVC statements? Even if I have docker.pp I 
still see these.

Dusty

[Bruno Wolff III]

On Fri, Oct 09, 2015 at 12:43:52 -0400,
  Dusty Mabe  wrote:
> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> > and this is in the journal:
> > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
> > msg='Unknown permission stop for class system 
> > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0 
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
> > msg='Unknown permission stop for class system 
> > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>
> Any comments on the USER_AVC statements? Even if I have docker.pp I 
> still see these.

I got something similar running getmail from cron. I asked about it on the 
selinux list but didn't get any suggestions on how to make a rule to allow this 
(audit2allow doesn't seem to handle this avc.)

[Daniel J Walsh]

On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
> On Fri, Oct 09, 2015 at 12:43:52 -0400,
>  Dusty Mabe  wrote:
> > On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> > > and this is in the journal:
> > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > msg='Unknown permission stop for class system
> > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > msg='Unknown permission stop for class system
> > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> >
> > Any comments on the USER_AVC statements? Even if I have docker.pp I
> > still see these.
>
> I got something similar running getmail from cron. I asked about it on
> the selinux list but didn't get any suggestions on how to make a rule
> to allow this (audit2allow doesn't seem to handle this avc.)
> _______________________________________________
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

If you systemctl daemon-rexec does the problem go away?

[Dusty Mabe]

On 10/10/2015 08:02 AM, Daniel J Walsh wrote:
> On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
> > On Fri, Oct 09, 2015 at 12:43:52 -0400,
> >   Dusty Mabe  wrote:
> > > On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> > > > and this is in the journal:
> > > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > > msg='Unknown permission stop for class system
> > > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > > msg='Unknown permission stop for class system
> > > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > >
> > > Any comments on the USER_AVC statements? Even if I have docker.pp I
> > > still see these.
> >
> > I got something similar running getmail from cron. I asked about it on
> > the selinux list but didn't get any suggestions on how to make a rule
> > to allow this (audit2allow doesn't seem to handle this avc.)
> > _______________________________________________
> > cloud mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/cloud
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
> If you systemctl daemon-rexec does the problem go away?

No, I still see them. I did an reexec and then started and stopped a 
container. The `USER_AVC` messages get spit out to the journal on both 
start and stop.

```
[root@footest ~]# journalctl -f | grep USER_AVC &
[1] 11388
[root@footest ~]# docker run -it --rm busybox /bin/sh
Oct 10 13:08:16 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission 
start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? 
addr=? terminal=?'
/ #
/ # exit
Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission 
stop for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? 
addr=? terminal=?'
Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission 
stop for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? 
addr=? terminal=?'
```

[Daniel J Walsh]

On 10/10/2015 09:09 AM, Dusty Mabe wrote:
> On 10/10/2015 08:02 AM, Daniel J Walsh wrote:
> > On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
> > > On Fri, Oct 09, 2015 at 12:43:52 -0400,
> > >   Dusty Mabe  wrote:
> > > > On 10/08/2015 03:06 PM, Dusty Mabe wrote:
> > > > > and this is in the journal:
> > > > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > > > msg='Unknown permission stop for class system
> > > > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > > > > Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
> > > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > > > msg='Unknown permission stop for class system
> > > > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > > >
> > > > Any comments on the USER_AVC statements? Even if I have docker.pp I
> > > > still see these.
> > >
> > > I got something similar running getmail from cron. I asked about it on
> > > the selinux list but didn't get any suggestions on how to make a rule
> > > to allow this (audit2allow doesn't seem to handle this avc.)
> > > _______________________________________________
> > > cloud mailing list
> > > [e-mail]
> > > https://admin.fedoraproject.org/mailman/listinfo/cloud
> > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> > If you systemctl daemon-rexec does the problem go away?
>
> No, I still see them. I did an reexec and then started and stopped a
> container. The `USER_AVC` messages get spit out to the journal on both
> start and stop.
> [root@footest ~]# journalctl -f | grep USER_AVC &
> [1] 11388
> [root@footest ~]# docker run -it --rm busybox /bin/sh
> Oct 10 13:08:16 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission start for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'
> / #
> / # exit
> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission stop for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'
> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission stop for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'

So this means that selinux policy does not define a start call for the
system class.  Meaning this is either a bug in systemd, systemd is
asking for a start access on system when it should be asking for it on a
service.  Or selinux-policy needs to add a start permission for system.
  I am thinking this is probably a problem with systemd.  Adding
Miroslav to
see if he knows.