Tough to come up with a subject for this one; it's really messing with my fragile mind. I have a system running RT3, which uses mod_perl or somesuch to run within the web server process. It needs to send mail, so it calls /usr/bin/sendmail, which happens to be exim on this system. If I understand things correctly, the sendmail process is supposed to start as or somehow transition to exim_t where it is then allowed to access whatever exim_t is allowed to access.
This was all working until I had to reboot the machine for unrelated reasons today. Now, RT3 can't send mail, and the audit logs seem to indicate that httpd_t is being denied things like writing to the exim spool file location. It really seems like somehow the transition to exim_t is not happening. Perhaps this will illustrate:
s ausearch -ts today |grep exim|audit2allow
#============= httpd_t ============== allow httpd_t exim_spool_t:dir { search setattr read write getattr remove_name open add_name }; allow httpd_t exim_spool_t:file { rename setattr read lock create write getattr unlink open append }; allow httpd_t proc_net_t:file { read getattr open }; allow httpd_t self:capability fowner; allow httpd_t smtp_port_t:tcp_socket name_connect;
Currently I've simply disabled selinux until I can understand what has happened. yum.log indicates that selinux-policy(-targeted) were updated on the 13th, but everything was working fine up until the today's reboot. No other related packages have been updated recently, and nothing was updated today. I suppose the reboot did boot me into a new kernel version (from kernel-2.6.29.6-217.2.3.fc11.x86_64 to kernel-2.6.30.5-43.fc11.x86_64).
ls -lZ /usr/sbin/exim
-rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim*
(which is what /usr/bin/sendmail is linked to via half a dozen symlinks due to alternatives).
- J<
On Thu, 17 Sep 2009 23:06:15 -0500 Jason L Tibbitts III tibbs@math.uh.edu wrote:
Tough to come up with a subject for this one; it's really messing with my fragile mind. I have a system running RT3, which uses mod_perl or somesuch to run within the web server process. It needs to send mail, so it calls /usr/bin/sendmail, which happens to be exim on this system. If I understand things correctly, the sendmail process is supposed to start as or somehow transition to exim_t where it is then allowed to access whatever exim_t is allowed to access.
This was all working until I had to reboot the machine for unrelated reasons today. Now, RT3 can't send mail, and the audit logs seem to indicate that httpd_t is being denied things like writing to the exim spool file location. It really seems like somehow the transition to exim_t is not happening. Perhaps this will illustrate:
s ausearch -ts today |grep exim|audit2allow
#============= httpd_t ============== allow httpd_t exim_spool_t:dir { search setattr read write getattr remove_name open add_name }; allow httpd_t exim_spool_t:file { rename setattr read lock create write getattr unlink open append }; allow httpd_t proc_net_t:file { read getattr open }; allow httpd_t self:capability fowner; allow httpd_t smtp_port_t:tcp_socket name_connect;
Currently I've simply disabled selinux until I can understand what has happened. yum.log indicates that selinux-policy(-targeted) were updated on the 13th, but everything was working fine up until the today's reboot. No other related packages have been updated recently, and nothing was updated today. I suppose the reboot did boot me into a new kernel version (from kernel-2.6.29.6-217.2.3.fc11.x86_64 to kernel-2.6.30.5-43.fc11.x86_64).
ls -lZ /usr/sbin/exim
-rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim*
(which is what /usr/bin/sendmail is linked to via half a dozen symlinks due to alternatives).
Just a thought but is your httpd_can_sendmail boolean still set?
Paul.
On 09/18/2009 02:46 AM, Paul Howarth wrote:
On Thu, 17 Sep 2009 23:06:15 -0500 Jason L Tibbitts III tibbs@math.uh.edu wrote:
Tough to come up with a subject for this one; it's really messing with my fragile mind. I have a system running RT3, which uses mod_perl or somesuch to run within the web server process. It needs to send mail, so it calls /usr/bin/sendmail, which happens to be exim on this system. If I understand things correctly, the sendmail process is supposed to start as or somehow transition to exim_t where it is then allowed to access whatever exim_t is allowed to access.
This was all working until I had to reboot the machine for unrelated reasons today. Now, RT3 can't send mail, and the audit logs seem to indicate that httpd_t is being denied things like writing to the exim spool file location. It really seems like somehow the transition to exim_t is not happening. Perhaps this will illustrate:
s ausearch -ts today |grep exim|audit2allow
#============= httpd_t ============== allow httpd_t exim_spool_t:dir { search setattr read write getattr remove_name open add_name }; allow httpd_t exim_spool_t:file { rename setattr read lock create write getattr unlink open append }; allow httpd_t proc_net_t:file { read getattr open }; allow httpd_t self:capability fowner; allow httpd_t smtp_port_t:tcp_socket name_connect;
Currently I've simply disabled selinux until I can understand what has happened. yum.log indicates that selinux-policy(-targeted) were updated on the 13th, but everything was working fine up until the today's reboot. No other related packages have been updated recently, and nothing was updated today. I suppose the reboot did boot me into a new kernel version (from kernel-2.6.29.6-217.2.3.fc11.x86_64 to kernel-2.6.30.5-43.fc11.x86_64).
ls -lZ /usr/sbin/exim
-rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim*
(which is what /usr/bin/sendmail is linked to via half a dozen symlinks due to alternatives).
Just a thought but is your httpd_can_sendmail boolean still set?
Paul.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I think if people would just get their hands around this document, it could help.
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_t...
SELinux is trying to say either you have a labeling problem in that exim no longer has the correct label. So httpd_t is not transitioning to the system_mail_t.
Or
For some reason the http_can_sendmail boolean is not set.
Of cours it could also be a bug in policy.
"PH" == Paul Howarth paul@city-fan.org writes:
PH> Just a thought but is your httpd_can_sendmail boolean still set?
Well, crap, it's off. I thought setting booleans was supposed to be permanent, but I guess you have to pass a flag and I suppose I might not have. Is there a way to check if any currently set booleans are not set permanently?
- J<
On Fri, 18 Sep 2009 11:23:40 -0500 Jason L Tibbitts III tibbs@math.uh.edu wrote:
"PH" == Paul Howarth paul@city-fan.org writes:
PH> Just a thought but is your httpd_can_sendmail boolean still set?
Well, crap, it's off. I thought setting booleans was supposed to be permanent, but I guess you have to pass a flag and I suppose I might not have. Is there a way to check if any currently set booleans are not set permanently?
I think permanently set booleans are recorded in /etc/selinux/targeted/modules/active/booleans.local but I may be wrong about that.
You need to use setsebool -P to set them permanently.
Paul.
OK, so what's confused me the most, I think, is that a naive interpretation of httpd_can_sendmail is that calls to sendmail will simply fail when it's off. Instead, the context transition just fails to happen, leading to the sendmail binary running with the wrong context and generating errors that make it look as if the MTA is misconfigured.
Anyway, problem solved and information saved for posterity. If, however, there's interest in making this failure less baffling to novices, consider actually failing when httpd calls sendmail instead of simply disabling the change of context (if that's even possible; I've no idea).
- J<
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Jason L Tibbitts III -
Paul Howarth