These look like you have disabled ipv6, somewhat incorrectly.  These AVC's indicate that the container will cause IPv6 to start running. We could don't audit these avcs/

container-selinux-2.16-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-39b21be7b7

container-selinux-2.16-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ba099329f

container-selinux-2.16-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ba099329f

container-selinux-2.16-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-39b21be7b7

container-selinux-2.17-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-483d4b64eb

container-selinux-2.17-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d722cd191

container-selinux-2.17-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d722cd191

container-selinux-2.18-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-78ffa38344

container-selinux-2.18-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e756e8fdde

container-selinux-2.18-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-78ffa38344

container-selinux-2.18-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e756e8fdde

container-selinux-2.18-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

I can still see the AVCs on F25 host with container-selinux-2:2.18-1.fc25.noarch when configuring freeipa-server:fedora-26

Moreover, I have noticed the following messages during the installation:

```
system.slice: Failed to set invocation ID on control group /system.slice/docker-5b9d4f31d91031388b0cf0951cddfa3d1e61b903ea39a90474d0f200cada714f.scope/system.slice, ignoring: Operation not permitted
systemd-journald.service: Failed to set invocation ID on control group /system.slice/docker-5b9d4f31d91031388b0cf0951cddfa3d1e61b903ea39a90474d0f200cada714f.scope/system.slice/systemd-journald.service, ignoring: Operation not permitted
fedora-readonly.service: Failed to set invocation ID on control group /system.slice/docker-5b9d4f31d91031388b0cf0951cddfa3d1e61b903ea39a90474d0f200cada714f.scope/system.slice/fedora-readonly.service, ignoring: Operation not permitted
```

Please show the latest avc's.  This looks like the contianer process is trying to set some content under /sys/fs/cgroup.

Which would indicate that you need container_manage_cgroup boolean turned on?

AVCs are here:

```
----
time->Wed Jun 14 04:42:00 2017
type=AVC msg=audit(1497429720.408:383): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:42:01 2017
type=AVC msg=audit(1497429721.409:384): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:42:46 2017
type=AVC msg=audit(1497429766.458:388): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:43:50 2017
type=AVC msg=audit(1497429830.409:389): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:44:54 2017
type=AVC msg=audit(1497429894.409:390): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:44:57 2017
type=AVC msg=audit(1497429897.442:391): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:45:58 2017
type=AVC msg=audit(1497429958.409:392): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:47:02 2017
type=AVC msg=audit(1497430022.408:394): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
----
time->Wed Jun 14 04:48:06 2017
type=AVC msg=audit(1497430086.667:398): avc:  denied  { module_request } for  pid=21944 comm="ntpd" kmod="net-pf-0" scontext=system_u:system_r:container_t:s0:c720,c775 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=0
```

I have checked my env and `container_manage_cgroup` is always turned on during test setup.

Sorry never scrolled up to the top.

Container-selinux does not fix this, sorry I added it to the chain.

The problem here is we don't want to allow containers to trigger the kernel to load kernel modules.  If you want to run this container you would have to load the kernel module outside of the container. 

modutil net-pf-0 
 
Should eliminate this issue.

I guess I could add a boolean to allow this behaviour, but I am not crazy about containers abiltiy to cause the kernel to modify itself.

container-selinux-2.18-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Dan,

Could you please clarify whether you introduced a boolean, tried to fix it in the policies, or is `modutil net-pf-0` a proposed workaround? The BZ does not clearly state that and those errors are still to be seen in container-selinux-2.18-1+.

I believe `modutil net-pf-0` (possibly proposed workaround) must be a typo as I don't think NSS has much to do with kernel (or at least I very much hope it doesn't) and because that's not how this command is usually used.

Nss is doing something with the network which is triggering the loading of the net-pf-0 kernel module.  I would rather not add the boolean, to allow containers to trigger loading kernel modules.

Digging into this a little deeper, I see that net-pf-0 is attempting to load a kernel module that is Unspecified. I have no idea what that means.

http://www.tldp.org/HOWTO/Kerneld/configuration.html

Indicates that:

"
Network protocol families (IPX, AppleTalk, AX.25)

Some network protocols can be loaded as modules as well. The kernel asks kerneld for a protocol family (e.g. IPX) with a request for net-pf-X where X is a number indicating what family is wanted. E.g. net-pf-3 is AX.25, net-pf-4 is IPX and net-pf-5 is AppleTalk; These numbers are determined by the AF_AX25, AF_IPX etc. definitions in the linux source file include/linux/socket.h. So to autoload the IPX module, you would need an entry like this in /etc/conf.modules:
"

This means that something happened on this host to cause the kernel to attempt to load net-pf-0, if you look in /usr/include/bits/socket.h, you will see that 0 is AF_UNSPEC.  

But if we allow the containers to trigger the loading of kernel modules, we would suddenly allow them to load network drivers like AppleTalk or other weird old parts of the kernel, these sections could potentially lead to syscall attcks, so I think it is better that we don't allow this access.  And force the Admin to load the kernel modules, or in this case most likely the app would work fine without the kernel module.

Paul and Steven could you read my comment above and indicate whether or not you think my interpretation is correct, or am I nuts?

I doubt that the two messages are related (Failed to set invocation id vs module_request).  Possibly systemd is encountering a different avc denial that is being silenced via dontaudit rule.  Try the following sequence:

1) Enable system call auditing and pathname reporting.

If you edit /etc/audit/rules.d/audit.rules (not to be confused with /etc/audit/audit.rules), and comment out the last line:
#-a task,never

Then add a watch or filter to turn on pathname collection:
echo "-w /etc/shadow -p w" > /etc/audit/rules.d/shadow.rules

The particular watch or filter is unimportant; it is the presence of any such watch/filter that turns on audit pathname collection.  Just don't pick one that will trigger too often or you'll generate lots of irrelevant audit messages.

Then you can run:
service auditd restart

And it should regenerate /etc/audit/audit.rules and reload that.

2) Strip dontaudit rules from your policy so that all denials are audited.
semodule -DB

3) Flush your audit logs before testing so we don't pick up old messages.
service auditd stop
rm /var/log/audit/audit.log* (or move them somewhere else for archival if you care)
service auditd start

4) Re-run your test case that was triggering the errors.
Then run ausearch -m avc -i -ts recent (or similar).

You should then get a series of records, including a type=PROCTITLE, type=PATH, type=CWD, type=SYSCALL, and type=AVC for each denial.  Some of the denials won't be important, e.g. siginh, rlimitinh, noatsecure denials.

Provide the relevant audit records.

5) Restore your system to its original state (i.e. re-enable dontaudit rules,
turn off syscall auditing and pathname collection).
   semodule -B
   rm /etc/audit/rules.d/shadow.rules
   Uncomment the last line of /etc/audit/rules.d/audit.rules.
   service auditd restart

This sequence likely ought to get captured somewhere if it isn't already.

Steven, not really what I was after, although that might be a good blog to put up.

I was wondering if you agree with me on not allowing containers to request the kernel to load modules?

Yes, I agree with that as a goal.  I am suspicious however that this net-pf-0 auto-loading indicates a bug in either the kernel or userspace, since that isn't valid AFAIK irrespective of SELinux.  That's why I want syscall audit record information, so I can see what triggered it.  And I think the other error message about setting invocation id is a separate, independent bug, which might be a policy bug.

For the record, in bug 1500287 we have established that this is a bug in ntpd code, not a bug or feature in nss.

At the same time, as container-selinux really did not address this issue, moving back to NOTABUG.