CPU %-usage surge associated with list archives
Hello everyone,
I am observing increased CPU(%) usage whenever a Mailman User Service runs. The journal tells me that SELinux is preventing httpd from map access on the file /var/lib/mailman/archives/private/<list>/<date>/<page>.html. A setroubleshoot service follows. This cycle repeats quickly, resulting in a surge in CPU (%) usage.
Why am I getting AVC denials {map} associated with list archives? Any ideas on how I should stabilize this?
Regards Onyeibo
On 11/15/20 8:01 AM, Onyeibo Oku wrote:
This would appear to be a SELinux issue. It probably requires some adjustment to your SELinux policies.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 11/15/20 8:01 AM, Onyeibo Oku wrote:
Why am I getting AVC denials {map} associated with list archives? Any ideas on how I should stabilize this?
We don't have a lot of SELinux experience here. For example, I myself have no clue what "AVC denials {map}" means (or even the individual words!) You probably want to ask this question (if you don't find out it's something obvious) on a SELinux channel. They would also be able to give you information that would help us decide if we should make a change because there's a real vulnerability rather than some kind of configuration mismatch.
This would appear to be a SELinux issue. It probably requires some adjustment to your SELinux policies.
We would appreciate it if you let us know what you find out. I don't see why access to archives would cause a security issue, but if it means you have to add special cases to an otherwise useful general policy, maybe we can do something to avoid triggering SELinux.
Also, we will probably never be SELinux experts, but having a sense of what common issues are is always helpful.
Steve
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
FWIW:
SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed.
On RHEL7 and its derivatives, the default SELinux policy includes a module for mailman's executable and data files which *in my experience* just works without modification when mailman is installed from an official RPM. It's even documented, if the policy docs are installed:
apropos mailman |grep selinux
mailman_cgi_selinux (8) - Security Enhanced Linux Policy for the mailman_cgi processes mailman_mail_selinux (8) - Security Enhanced Linux Policy for the mailman_mail processes mailman_queue_selinux (8) - Security Enhanced Linux Policy for the mailman_queue processes
It would certainly be possible to break that by assigning the wrong SELinux labels to the mailman files, perhaps by installing from the unpackaged source. Fixing that sort of error is probably simple, but it would depend on what specifically was done. A simple 'restorecon -Rv /' will fix a lot of issues, but it isn't instantaneous and stomps on any customization that hasn't been written into the persistent policy.
-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Bill Cole writes:
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
Thanks for the reply!
Also FWIW, I'm explaining here why I don't think this is a Mailman issue. If there is a vulnerability in our distribution, and the SELinux policy is pointing it out, we (I think I speak for all the core devs here ;-) want to fix it.
Yes, I was already aware that that is the "theoretically correct" policy, and had guessed that SELinux follows it.
Aha. Now *that* is *very* useful information! So I assume that would also apply to sufficiently recent CentOS, and most likely to Fedora. And it's something to look up on Debian and Ubuntu.
Many thanks!
Regards, Steve
It's even documented, if the policy docs are installed:
On 16 Nov 2020, at 2:17, Stephen J. Turnbull wrote:
Right. I agree that it is not a problem with anything Mailman is doing that is in any way dangerous or even that it is something that the base distribution should attempt to deal with.
Yes.
And it's something to look up on Debian and Ubuntu.
It seems that https://github.com/SELinuxProject/refpolicy is the upstream basis for the EL-family default policy and it appears to have build switches for other lineages. I believe that the EL family is the only one that has SELinux enabled and enforcing by default.
-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
For general info, here is CentOS’s SELinux HowTo:
https://wiki.centos.org/HowTos/SELinux
Another good introduction:
https://www.digitalocean.com/community/tutorial_series/an-introduction-to-se...
Or you can just turn it off and trust the firewall if this is the only thing the server does...
On Nov 15, 2020, at 10:43 PM, Bill Cole <mailmanu-20190215@billmail.scconsult.com<mailto:mailmanu-20190215@billmail.scconsult.com>> wrote:
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
FWIW:
- SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed.
-- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group
Institutions do not have opinions, merely customs
On 11/15/20 9:43 PM, Bill Cole wrote:
And several years ago (in the 2.1.5 timeframe), RedHat modified their Mailman package to be FHS compliant for the specific purpose of avoiding SELinux security violations.
See <https://wiki.list.org/x/8486953> and <https://wiki.list.org/x/17892071>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/17/2020 8:30 PM, Stephen J. Turnbull wrote:
Are we FHS conformant? If not, why would it be a bad idea to become FHS-conformant (aaside from the effort required)?
I don't think so and that would probably break non linux systems (e.g. xBSD). Might be OK to add FHS as an option to the configure script if anyone wanted to go that route.
Later,
z!
On 11/17/20 8:30 PM, Stephen J. Turnbull wrote:
It's possible, but all we know is the OP moved lists from one server to another - see <https://mail.python.org/archives/list/mailman-users@python.org/thread/IQUVN5...>.
We have no idea how Mailman is installed on the new server.
Are we FHS conformant? If not, why would it be a bad idea to become FHS-conformant (aaside from the effort required)?
For Mailman 2.1, it requires RedHat's patch. See <https://wiki.list.org/x/17892071>
For Mailman 3 putting
layout: fhs
in the [mailman] section of mailman.cfg should create an FHS compliant layout.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/15/20 8:01 AM, Onyeibo Oku wrote:
This would appear to be a SELinux issue. It probably requires some adjustment to your SELinux policies.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 11/15/20 8:01 AM, Onyeibo Oku wrote:
Why am I getting AVC denials {map} associated with list archives? Any ideas on how I should stabilize this?
We don't have a lot of SELinux experience here. For example, I myself have no clue what "AVC denials {map}" means (or even the individual words!) You probably want to ask this question (if you don't find out it's something obvious) on a SELinux channel. They would also be able to give you information that would help us decide if we should make a change because there's a real vulnerability rather than some kind of configuration mismatch.
This would appear to be a SELinux issue. It probably requires some adjustment to your SELinux policies.
We would appreciate it if you let us know what you find out. I don't see why access to archives would cause a security issue, but if it means you have to add special cases to an otherwise useful general policy, maybe we can do something to avoid triggering SELinux.
Also, we will probably never be SELinux experts, but having a sense of what common issues are is always helpful.
Steve
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
FWIW:
SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed.
On RHEL7 and its derivatives, the default SELinux policy includes a module for mailman's executable and data files which *in my experience* just works without modification when mailman is installed from an official RPM. It's even documented, if the policy docs are installed:
apropos mailman |grep selinux
mailman_cgi_selinux (8) - Security Enhanced Linux Policy for the mailman_cgi processes mailman_mail_selinux (8) - Security Enhanced Linux Policy for the mailman_mail processes mailman_queue_selinux (8) - Security Enhanced Linux Policy for the mailman_queue processes
It would certainly be possible to break that by assigning the wrong SELinux labels to the mailman files, perhaps by installing from the unpackaged source. Fixing that sort of error is probably simple, but it would depend on what specifically was done. A simple 'restorecon -Rv /' will fix a lot of issues, but it isn't instantaneous and stomps on any customization that hasn't been written into the persistent policy.
-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Bill Cole writes:
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
Thanks for the reply!
Also FWIW, I'm explaining here why I don't think this is a Mailman issue. If there is a vulnerability in our distribution, and the SELinux policy is pointing it out, we (I think I speak for all the core devs here ;-) want to fix it.
Yes, I was already aware that that is the "theoretically correct" policy, and had guessed that SELinux follows it.
Aha. Now *that* is *very* useful information! So I assume that would also apply to sufficiently recent CentOS, and most likely to Fedora. And it's something to look up on Debian and Ubuntu.
Many thanks!
Regards, Steve
It's even documented, if the policy docs are installed:
On 16 Nov 2020, at 2:17, Stephen J. Turnbull wrote:
Right. I agree that it is not a problem with anything Mailman is doing that is in any way dangerous or even that it is something that the base distribution should attempt to deal with.
Yes.
And it's something to look up on Debian and Ubuntu.
It seems that https://github.com/SELinuxProject/refpolicy is the upstream basis for the EL-family default policy and it appears to have build switches for other lineages. I believe that the EL family is the only one that has SELinux enabled and enforcing by default.
-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
For general info, here is CentOS’s SELinux HowTo:
https://wiki.centos.org/HowTos/SELinux
Another good introduction:
https://www.digitalocean.com/community/tutorial_series/an-introduction-to-se...
Or you can just turn it off and trust the firewall if this is the only thing the server does...
On Nov 15, 2020, at 10:43 PM, Bill Cole <mailmanu-20190215@billmail.scconsult.com<mailto:mailmanu-20190215@billmail.scconsult.com>> wrote:
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote:
I don't see why access to archives would cause a security issue,
FWIW:
- SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed.
-- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group
Institutions do not have opinions, merely customs
On 11/15/20 9:43 PM, Bill Cole wrote:
And several years ago (in the 2.1.5 timeframe), RedHat modified their Mailman package to be FHS compliant for the specific purpose of avoiding SELinux security violations.
See <https://wiki.list.org/x/8486953> and <https://wiki.list.org/x/17892071>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/17/2020 8:30 PM, Stephen J. Turnbull wrote:
Are we FHS conformant? If not, why would it be a bad idea to become FHS-conformant (aaside from the effort required)?
I don't think so and that would probably break non linux systems (e.g. xBSD). Might be OK to add FHS as an option to the configure script if anyone wanted to go that route.
Later,
z!
On 11/17/20 8:30 PM, Stephen J. Turnbull wrote:
It's possible, but all we know is the OP moved lists from one server to another - see <https://mail.python.org/archives/list/mailman-users@python.org/thread/IQUVN5...>.
We have no idea how Mailman is installed on the new server.
Are we FHS conformant? If not, why would it be a bad idea to become FHS-conformant (aaside from the effort required)?
For Mailman 2.1, it requires RedHat's patch. See <https://wiki.list.org/x/17892071>
For Mailman 3 putting
layout: fhs
in the [mailman] section of mailman.cfg should create an FHS compliant layout.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (6)
-
Bill Cole -
Bruce Johnson -
Carl Zwanzig -
Mark Sapiro -
Onyeibo Oku -
Stephen J. Turnbull