unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.conf

[Robert Edmonds]

Tomas Hozza via Unbound-users wrote:
> On 04.11.2015 17:35, Phil Mayers wrote:
> > The code tries to open an IPv6 socket, the kernel tries to load the module, SELinux denies and logs this. Each of these items is by design. Which are you suggesting should change?
> 
> I think it makes sense. I'm just not that familiar with how IPv6 works in kernel,
> therefore I was trying to ask you for more information so I can possibly convince
> the Fedora user that the Unbound's behavior is expected and correct.

Hi, Tomas:

Given that this same bug has been reported in:

    https://bugzilla.redhat.com/show_bug.cgi?id=641836
        [named,sshd,sendmail,rndc]

and duplicates of it:

    https://bugzilla.redhat.com/show_bug.cgi?id=669047
        [sshd]

    https://bugzilla.redhat.com/show_bug.cgi?id=696256
        [rpc.statd]

    https://bugzilla.redhat.com/show_bug.cgi?id=696371
        [named]

    https://bugzilla.redhat.com/show_bug.cgi?id=703733
        [dhcpd]

    https://bugzilla.redhat.com/show_bug.cgi?id=722751
        [sendmail]

    https://bugzilla.redhat.com/show_bug.cgi?id=728969
        [rpc.nfsd]

and that the bug has been closed with status CLOSED CANTFIX, can't you
just mark this as another duplicate and move on?

> > Is it the audit log that is annoying people? If so, the SELinux policy should be a dontaudit.
> 
> I think it is the fact that they disabled the IPv6, but some userspace component
> is trying to load into kernel a module they they don't want to be loaded.

Given that IPv6 is compiled into the kernel rather than as a module, the
kernel can't load ipv6.ko.  Seems like the real bug is the kernel trying
to load a module that doesn't exist?  (Or, rather, the kernel trying to
autoload the IPv6 module even though it's compiled in and ipv6.disable=1
is specified on the kernel command line.  But apparently the code that
checks the ipv6.disable command line is inside the IPv6 module itself,
leading to a chicken-and-egg problem.)

If the kernel developers don't consider this interaction a bug or don't
consider ipv6.disable=1 a supported configuration, it seems like the
only other solution is to make auditd not log this particular message.
(Note that the only bad behavior reported in any of these bugs is the
log message generated by auditd, not any bad behavior on the part of the
userspace component that happened to be running at the time.)

The only other option would appear to be to convince users to not
attempt to disable IPv6 :-)

-- 
Robert Edmonds
edmonds at debian.org