Hello, After a yum update last night, I had a CenOS 5.4 i386 system pull in the following selinux updates: Jan 07 21:39:14 Updated: selinux-policy-2.4.6-255.el5_4.3.noarch Jan 07 21:39:31 Updated: selinux-policy-targeted-2.4.6-255.el5_4.3.noarch
This machine has SELinux set to Enforcing.
This morning, I see I got the following email from Cron: /etc/cron.daily/0logwatch:
sendmail: warning: premature end-of-input on /usr/sbin/postdrop -r while reading input attribute name sendmail: fatal: root(0): unable to execute /usr/sbin/postdrop -r: Success
Frankly, this error message means little to mean... in the course of troubleshooting, I tried this: # setenforce Permissive # /etc/cron.daily/0logwatch
And it worked! The logwatch email sends without error. If I turn SELinux back to Enforcing, then the email error is consistently repeated.
What confuses me is that, when SElinux enforcing causes this error to occur, no SELinux or AVC messages appear in /var/log/messages or /vaar/log/secure or /var/log/audit/audit.log.
Has anyone else seen this? Any suggestions would be appreciated. Thanks!
On 01/08/2010 08:28 AM James Rankin wrote:
Hello, After a yum update last night, I had a CenOS 5.4 i386 system pull in the following selinux updates: Jan 07 21:39:14 Updated: selinux-policy-2.4.6-255.el5_4.3.noarch Jan 07 21:39:31 Updated: selinux-policy-targeted-2.4.6-255.el5_4.3.noarch
This machine has SELinux set to Enforcing.
This morning, I see I got the following email from Cron: /etc/cron.daily/0logwatch:
sendmail: warning: premature end-of-input on /usr/sbin/postdrop -r while reading input attribute name sendmail: fatal: root(0): unable to execute /usr/sbin/postdrop -r: Success
Frankly, this error message means little to mean... in the course of troubleshooting, I tried this: # setenforce Permissive # /etc/cron.daily/0logwatch
And it worked! The logwatch email sends without error. If I turn SELinux back to Enforcing, then the email error is consistently repeated.
What confuses me is that, when SElinux enforcing causes this error to occur, no SELinux or AVC messages appear in /var/log/messages or /vaar/log/secure or /var/log/audit/audit.log.
Has anyone else seen this? Any suggestions would be appreciated. Thanks!
By setting selinux to "permissive", you've, in effect, turned it off. SElinux will still provide messages about infractions, but won't prevent things from running... i.e., it is no longer guarding your system.
hth, ken
By setting selinux to "permissive", you've, in effect, turned it off.
SElinux will still provide messages about infractions, but won't prevent things from running... i.e., it is no longer guarding your system.
hth, ken
Thanks for the reply; the fact that the error only occurs when Enforcing is basically the point I am trying to make...
The absence of AVC messages is what I found troubling. In the past, every SELinux denial I've seen has been logged. I will increase the loglevel and try to get more info.
On Fri, Jan 8, 2010 at 8:28 AM, James Rankin rankin.james@gmail.com wrote:
Frankly, this error message means little to mean... in the course of troubleshooting, I tried this: # setenforce Permissive # /etc/cron.daily/0logwatch
And it worked! The logwatch email sends without error. If I turn SELinux back to Enforcing, then the email error is consistently repeated.
What confuses me is that, when SElinux enforcing causes this error to occur, no SELinux or AVC messages appear in /var/log/messages or /vaar/log/secure or /var/log/audit/audit.log.
Has anyone else seen this? Any suggestions would be appreciated. Thanks!
That's interesting... Have you tried increasing the loglevel? It's a kernel option, unfortunately, and enabled with an audit=xx on the grub boot. It might give you more than you're seeing in the audit log. You may also want to try a relabel and manually check the context of all associated binaries.
That's interesting... Have you tried increasing the loglevel? It's a
kernel option, unfortunately, and enabled with an audit=xx on the grub boot. It might give you more than you're seeing in the audit log. You may also want to try a relabel and manually check the context of all associated binaries.
I will try both of these steps. Thanks!
On Fri, Jan 8, 2010 at 7:54 PM, James Rankin rankin.james@gmail.com wrote:
For anyone else finding this:
https://bugzilla.redhat.com/show_bug.cgi?id=553492
and also
Oh whew...From the other thread it looks like this bit a few people.
On Jan 8, 2010, at 4:54 PM, James Rankin wrote:
For anyone else finding this:
Here's a stupid question, can we install the rpm provided on the link above (see comment 12)? Or is the correct way to modify the local policy?
Thanks,
Dianne
-
Dianne Yumul -
James Rankin -
ken -
Kwan Lowe