FYI:
rhbz#1231946 - unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.conf
https://bugzilla.redhat.com/show_bug.cgi?id=1231946
Paul
Hi, Paul:
I'm a bit confused. unbound-anchor is an ordinary program that uses the
sockets API, so it should have no reason to read Linux kernel specific
sysctl's or change behavior based on their values, since sysctl's are
parameters for the kernel.
kmod="net-pf-10" is the IPv6 protocol family, and Red Hat kernels have
CONFIG_IPV6=y these days, so it could not autoload the module anyway.
Maybe IPv6 is not really fully disabled, and unbound-anchor attempting
to open an AF_INET6 socket triggers this message?
I came across this page (https://access.redhat.com/solutions/482253)
which seems to match the problem description, but the solution is
paywalled, perhaps you have better access 
Agreed. What's happening here is a user-space attempt to open an AF_INET6 socket is causing a modprobe, likely because the reporter has blocked the IPv6 kernel module from loading ("I don't trust IPv6").
They erroneously believe the sysctl would stop this, when all it does is disable IPv6 on all interfaces - it's nothing to do with application behaviour or module loading control.
If there's a bug anywhere here, it's in the SELinux policy blocking the module_request, but I doubt even that.
Trying to force IPv6 to not load on a Linux system causes all sorts of subtle errors these days, and should not IMHO be a supported use-case.
Believe it or not, there are users who are doing it and think it is the right thing to do [1]. I think it is good that SELinux is not allowing the module to be loaded, because it is exactly what SELinux is for - another level of defense.
If you have some strong technical argument for this behavior I would be more than glad to hear it. The reason is that similar people will fight hard against having Unbound as the default DNS resolver in Fedora, which is our ultimate plan. Ability to spare hundreds of emails arguing with them would be great
Note that we have the same bug report for dnssec-trigger, too.
[1] https://lists.fedoraproject.org/pipermail/devel/2015-November/216417.html
Regards,
Which "behaviour"?
I'm honestly confused. As far as I can tell, everything is working as designed here.
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?
Is it the audit log that is annoying people? If so, the SELinux policy should be a dontaudit.
Can we agree that unbound-anchor should not be reading sysctls to change it's behaviour?
Hi,
>If you have some strong technical argument for this behavior I would
>be more than glad to hear it. The reason is that similar people will
>fight hard against having Unbound as the default DNS resolver in
>Fedora, which is our ultimate plan. Ability to spare hundreds of
>emails arguing with them would be greatWhich "behaviour"?
I'm honestly confused. As far as I can tell, everything is working as
designed here.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?
If I understand correctly, there is no ipv6.ko module on the kernel in
question that can be autoloaded; at least on my Fedora 20 and CentOS 7
machines, the kernels are built with CONFIG_IPV6=y.
When "ipv6.disable=1" is set on the kernel command line, it looks like
the (built-in) IPv6 code bails out without registering the IPv6 TCP,
UDP, etc. protocols:
https://github.com/torvalds/linux/blob/v4.3/net/ipv6/af_inet6.c#L839-L850
So, IIUC, when a userspace program tries to create an AF_INET6 socket,
the kernel sees that the requested protocol isn't available (due to this
early bail out from the ipv6 module), and tries to load the "net-pf-10"
module, even though this would have been provided by code statically
compiled into the kernel.
Is the problem perhaps that "ipv6.disable=1" on the kernel command line
should be accompanied by "alias net-pf-10 off" in the modprobe
configuration in order to prevent useless autoloading attempts?
Is it the audit log that is annoying people? If so, the SELinux policy
should be a dontaudit.
I can't see how this audit message wouldn't be triggered by basically
any program that creates an IPv6 socket, which should be close to any
program that uses the network by now?
Can we agree that unbound-anchor should not be reading sysctls to change
it's behaviour?
I do, that's just crazy
The userspace interface for detecting the lack of IPv6 support is: if
the call to socket() fails (probably with EAFNOSUPPORT or
EPROTONOSUPPORT), then it's not supported. And any sane userspace
program already checks for socket() failures.
If I understand correctly, there is no ipv6.ko module on the kernel in
question that can be autoloaded; at least on my Fedora 20 and CentOS 7
machines, the kernels are built with CONFIG_IPV6=y.
Good point; that's what I see too (and an entirely sensible default it is).
Is the problem perhaps that "ipv6.disable=1" on the kernel command line
should be accompanied by "alias net-pf-10 off" in the modprobe
configuration in order to prevent useless autoloading attempts?
Is that config read by modprobe after the kernel has called it? In which case it'll still trigger (and deny) the probe. It's been so long since I looked at module loading I can't remember.
I can't see how this audit message wouldn't be triggered by basically
any program that creates an IPv6 socket, which should be close to any
program that uses the network by now?
They might be running under SELinux contexts which either permit or dontaudit the module load I suppose? But I agree, almost everything is going to be v6-aware at this point.
Can we agree that unbound-anchor should not be reading sysctls to change
it's behaviour?I do, that's just crazy
The userspace interface for detecting the lack of IPv6 support is: if
the call to socket() fails (probably with EAFNOSUPPORT or
EPROTONOSUPPORT), then it's not supported. And any sane userspace
program already checks for socket() failures.
That's my understanding too. Most apps won't even end up that low-level, having probably used getaddrinfo() to iterate across a list of sockets, and glibc having filtered out unavailable address families before then.
>Is the problem perhaps that "ipv6.disable=1" on the kernel command line
>should be accompanied by "alias net-pf-10 off" in the modprobe
>configuration in order to prevent useless autoloading attempts?Is that config read by modprobe after the kernel has called it? In which
case it'll still trigger (and deny) the probe. It's been so long since I
looked at module loading I can't remember.
I don't know that much about SELinux. Are these "module_request"
denials triggered at the point where the kernel is about to perform the
upcall into userspace to invoke modprobe, or are they triggered after
the modprobe runs and calls back into the kernel to request the module
load? (If the former, then "alias net-pf-10 off" won't help, of
course.)
>I can't see how this audit message wouldn't be triggered by basically
>any program that creates an IPv6 socket, which should be close to any
>program that uses the network by now?They might be running under SELinux contexts which either permit or
dontaudit the module load I suppose? But I agree, almost everything is going
to be v6-aware at this point.
Right, so this looks like a duplicate of
https://bugzilla.redhat.com/show_bug.cgi?id=641836, and wow that bug has
a lot of dupes. So this isn't an Unbound problem at all.
According to a blog post (http://danwalsh.livejournal.com/47118.html),
it would appear the better option is to disable IPv6 addressing. Or
figure out how to get the system to deny the request without logging it
if it bothers you so much, I guess.
Hi Phil.
Sorry for the late response.
If you have some strong technical argument for this behavior I would
be more than glad to hear it. The reason is that similar people will
fight hard against having Unbound as the default DNS resolver in
Fedora, which is our ultimate plan. Ability to spare hundreds of
emails arguing with them would be greatWhich "behaviour"?
I'm honestly confused. As far as I can tell, everything is working as designed here.
I meant the situation that the user disabled the IPv6, but Unbound as IPv6
aware application triggers a request to load the module through calling the
standard syscall.
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.
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.
Can we agree that unbound-anchor should not be reading sysctls to change it's behaviour?
Definitely. I really think Unbound should not read the file and just use standard syscall
and check for errors - as it already does.
Regards,
> 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