Bug 1926256

Hubert and Stanislav,

How the ipv6 module is disabled? There are multiple ways.
What is the purpose of disabling, like for the boot time or for the system lifetime? Which use case it covers?
What is the expected behaviour of services when ipv6 is disabled?

See also bz#1931450
https://access.redhat.com/solutions/8709
https://danwalsh.livejournal.com/47118.html

(In reply to Zdenek Pytela from comment #3)
> Hubert and Stanislav,
> 
> How the ipv6 module is disabled? There are multiple ways.

Steps to Reproduce:
1. add ipv6.disable=1 do kernel command line

> What is the purpose of disabling, like for the boot time or for the system
> lifetime? Which use case it covers?

to cover a use case reported by customer, they reported that openssl didn't work with ipv6 disabled, we fixed it, we're running regression test case for that

> What is the expected behaviour of services when ipv6 is disabled?

continue to work as if IPv6 was unroutable/unavilable

> See also bz#1931450
> https://access.redhat.com/solutions/8709
> https://danwalsh.livejournal.com/47118.html

From the article:

> It still loads the module but unhooks almost all of the calls into the module.

that "almost all" is precisely the issue and the reason for use of ipv6.disable=1 on command line instead of any other approach

Hubert,

Thank you, now I think I understand, for sure it is different to bz#1931450. What we can do in the policy is to dontaudit these messages, i. e. silence them not to be audited, either for enumerated list of domains or for all services.

Is it a bit questionable though as it makes further troubleshooting harder, so these audit records can be taken as indication of a possible problem.

We currently have:
# sesearch --dontaudit -t kernel_t -c system -p module_request
dontaudit dnssec_trigger_t kernel_t:system module_request;
dontaudit init_t kernel_t:system module_request;
dontaudit ipsec_mgmt_t kernel_t:system module_request;
dontaudit openshift_domain kernel_t:system module_request;
dontaudit pcp_pmie_t kernel_t:system module_request;
dontaudit pcscd_t kernel_t:system module_request;
dontaudit postfix_domain kernel_t:system module_request;
dontaudit sandbox_xserver_t kernel_t:system module_request;
dontaudit sshd_keygen_t kernel_t:system module_request;
dontaudit systemd_rfkill_t kernel_t:system module_request;
dontaudit tlp_t kernel_t:system module_request;
dontaudit xguest_t kernel_t:system module_request;

ipv6.disable=1 isn't default configuration, so it requiring additional audit rule(s) to work as expected isn't exactly unexpected...
dunno if the rule should be to blanket allow module loading, or if it should be to just suppress these messages; but it looks to me like we should document the solution, then we can use it in the test cases that run in this configuration

Hubert,

There is no definite answer, but I tend not to dontaudit these messages in the policy, that is leave the denial exposed instead of hiding it.

For sure the applications need to get the information that loading of the module failed. Exposing the error in audit log is  a possible way to point to the problem.

If it actually is needed to allow the attempts, the domain_kernel_load_modules SELinux boolean can be turned on:
domain_kernel_load_modules     (off  ,  off)  Allow all domains to have the kernel load modules
The boolean is off by default.

Is this satisfactory explanation and resolution?

The problem is that the attempt at loading the module doesn't come from the application, I'm guessing it comes from glibc.
So we can't limit the rule to specific domains, any application that binds to a socket will likely attempt to load that module.
We could allow all domains to load modules, and depend on the kernel to block the loading of the ipv6 module, but then we make the system less secure, as attacker can use it to load some obsolete module.
Or we could stop logging, and make debugging more complex for applications that have legitimate use case of loading modules...

With my security hat on, I'd go for the latter, but I'm thinking that documenting both approaches and their individual downsides is more user friendly.

All things considered, we decided to let the problem rather exposed and visible for further troubleshooting and neither allow nor dontaudit the denials.

The issue is going to be closed now, but if you believe that the decision needs to be reconsidered, feel free to reopen this bug and attach information regarding severity of the problem.