Red Hat Bugzilla – Bug 1276754
attempting to control system
Last modified: 2016-01-19 05:51:46 EST
Description of problem: "SELinux is preventing sendmail from using the sys_resource capability. Plugin: sys_resource you do not want processes to require capabilities to use up all the system resources on your system;If you do not want processes to require capabilities to use up all the system resources on your system; you need to diagnose why your system is running out of system resources and fix the problem. <snip> Fix the cause of the SYS_RESOURCE on your system." Version-Release number of selected component (if applicable): 22 How reproducible: not known yet Steps to Reproduce: not known system semi-busy but not heavily swamped burning bdrom playing mp3 -- free -m shows: total used free shared buff/cache available Mem: 24009 1316 229 25 22464 22539 Swap: 15355 0 15355 swap size was calculated before RAM upgrade -- then this comes up Actual results: ?? Expected results: this sounds like something is wrong but I dont know why. sendmail being the /var/mail daemon? I dont have mail server otherwise configured.This is a workstation at home.The only thing I should be serving is an open torrent, which client isnt even running.
Is sendmail installed? If it is clean f22 workstation installation, it shouldn't be installed and this may be error regarding different package. Please provide output of 'rpm -q sendmail'.
I checked the code, it seems sendmail alters rlimits in a way that shouldn't trigger SYS_RESOURCE SELinux AVC. But sendmail is running under root, thus it already has SYS_RESOURCE capability. I think the reported AVC may happen if your system is running out of resources or if you lower the limits in e.g. /etc/security/limits.conf or ulimit. I am currently unsure whether sendmail should drop SYS_RESOURCE capability, probably yes, but AFAIK no MTA (sendmail, postfix, exim, ...) currently do it.
Moving to rawhide.
I thought about it more and now I think there is no bug. Currently there are the following distinct (partly overlapping) Linux security models supported in Fedora: - legacy SETUID applications - capabilities aware applications - SELinux Sendmail is legacy SETUID application. It knows nothing about CAP_SYS_RESOURCE and other capabilities. The following is probably happening: - system is running out of resources - e-mail is sent through sendmail - sendmail tries to use reserved system resources, because it correctly thinks it is fully privileged/unlimited root process - SELinux blocks sendmail from using reserved system resources This is not fault of sendmail, nor SELinux. Consider situation where you want administrator's e-mails to be sent even in situations when user processes depleted system resources (e.g. to be warned that it happened). In such situation you can just write your custom SELinux policy allowing such behaviour. On the other hand you may not want to be unable to root login into your server, because your sendmail process ate the remaining reserved system resources. So the default SELinux rule warned you that such situation happened and blocked the non-critical process from using the reserved resources. I think it is the safest approach for most of the scenarios. I think you should do exactly what is written in the SELinux message: "you need to diagnose why your system is running out of system resources and fix the problem". E.g. add more RAM, and if you observe there is application leaking your RAM, report bug against such application. Regarding sendmail, it is not mandatory on the desktop. Fedora is currently MTA-less. You can usually remove it with no harm (in case you keep installing programs not explicitly requiring it): # dnf remove 'sendmail-*' Also check your rlimits for misconfiguration: /etc/security/limits.conf and ulimit command: $ ulimit -a and increase the limits if needed.
(In reply to Jaroslav Škarvada from comment #4) > # dnf remove 'sendmail-*' > # dnf remove 'sendmail*'
(In reply to Jaroslav Škarvada from comment #4) > Also check your rlimits for misconfiguration: > /etc/security/limits.conf And: /etc/security/limits.d/*