Rebooted, permissive, setroubleshooter going nuts.
Gene Heskett
gene.heskett at verizon.net
Thu Mar 5 14:19:51 UTC 2009
On Thursday 05 March 2009, Paul Howarth wrote:
>Gene Heskett wrote:
>> On Thursday 05 March 2009, Gene Heskett wrote:
>>> On Wednesday 04 March 2009, Gene Heskett wrote:
>>>> Greetings;
>>>>
>>>> And a portion of this lists archive on this box has gone missing to
>>>> boot. So I can't look up the command to extract all these hits, about
>>>> once every 2 minutes or so, to a logfile I can post. And when I click
>>>> on the star, it tells me the connection has been lost to
>>>> /var/run/setroubleshoot/setroubleshoot_server. But there is a zero
>>>> length file there, generated when I rebooted to 2.6.29-rc7 5:18 ago WTH?
>>>>
>>>> And I just found a very short setroubleshooter.log which I will attach.
>>>> It looks like it got a tummy ache just a few minutes ago.
>>>>
>>>> I think I will follow what I did with 29-rc7, and not build any sound
>>>> modules for anything except the audigy2, cuz now I have sound, akonadi
>>>> even starts!
>>>>
>>>> Help?
>>>
>>> No comment. Can anyone tell me why, when looking at the log messages,
>>> and it tells me to get the full report by running sealert with -l
>>> hashnumber, I as root am denied? From a root shell:
>>> [root at coyote log]# sealert -l 1ed4cefd-aa3b-4727-b9ef-28b8e2cbb42c
>>> failed to connect to server: Connection refused
>>>
>>> I am back on a 2.6.28.7 kernel now. And setroubleshooter's screen alerts
>>> in time with the kmail pongs of new mail coming are contributing to my
>>> loss of sanity or whatever. Somehow it has decided that fetchmail isn't
>>> supposed to be able to access its users directory/.f, uhh, I was gonna
>>> run it and get the exact file and the connection to its server has been
>>> lost, again. I thought it was funny that the reject messages were going
>>> into the system log...
>>>
>>> Uptodate Fedora 10. x86_64 running 32 bit.
>>>
>>> A 'service setroubleshoot restart' restarts it though. Anybody have a
>>> clue, I seem to be fresh out, and I'm about to compile it out.
>>
>> Ok, the restart allowed me to collect the most recent hit from sealert:
>> ===============================
>> [root at coyote init.d]# sealert -l 2ada4c61-64cb-40d7-8268-83488b12426e
>>
>> Summary:
>>
>> SELinux is preventing procmail (procmail_t) "append" to
>> /var/log/fetchmail.log (var_log_t).
>>
>> Detailed Description:
>>
>> [SELinux is in permissive mode, the operation would have been denied but
>> was permitted due to permissive mode.]
>>
>> SELinux is preventing procmail (procmail_t) "append" to
>> /var/log/fetchmail.log (var_log_t). The SELinux type var_log_t, is a
>> generic type for all files in the directory and very few processes
>> (SELinux Domains) are allowed to write to this SELinux type. This type of
>> denial usual indicates a mislabeled file. By default a file created in a
>> directory has the gets the context of the parent directory, but SELinux
>> policy has rules about the creation of directories, that say if a process
>> running in one SELinux Domain (D1) creates a file in a directory with a
>> particular SELinux File Context (F1) the file gets a different File
>> Context (F2). The policy usually allows the SELinux Domain (D1) the
>> ability to write, unlink, and append on (F2). But if for some reason a
>> file
>> (/var/log/fetchmail.log) was created with the wrong context, this domain
>> will be denied. The usual solution to this problem is to reset the file
>> context on the target file, restorecon -v '/var/log/fetchmail.log'. If the
>> file context does not change from var_log_t, then this is probably a bug
>> in policy. Please file a bug report
>> (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the
>> selinux-policy package. If it does change, you can try your application
>> again to see if it works. The file context could have been mislabeled by
>> editing the file or moving the file from a different directory, if the
>> file keeps getting mislabeled, check the init scripts to see if they are
>> doing something to mislabel the file.
>>
>> Allowing Access:
>>
>> You can attempt to fix file context by executing restorecon -v
>> '/var/log/fetchmail.log'
>>
>> Fix Command:
>>
>> restorecon '/var/log/fetchmail.log'
>>
>> Additional Information:
>>
>> Source Context system_u:system_r:procmail_t:s0
>> Target Context system_u:object_r:var_log_t:s0
>> Target Objects /var/log/fetchmail.log [ file ]
>> Source procmail
>> Source Path /usr/bin/procmail
>> Port <Unknown>
>> Host coyote.coyote.den
>> Source RPM Packages procmail-3.22-22.fc10
>> Target RPM Packages
>> Policy RPM selinux-policy-3.5.13-46.fc10
>> Selinux Enabled True
>> Policy Type targeted
>> MLS Enabled True
>> Enforcing Mode Permissive
>> Plugin Name mislabeled_file
>> Host Name coyote.coyote.den
>> Platform Linux coyote.coyote.den 2.6.28.7 #6 SMP
>> PREEMPT Wed Mar 4 23:08:30 EST 2009 i686 athlon Alert Count
>> 63
>> First Seen Sat Feb 28 16:34:21 2009
>> Last Seen Thu Mar 5 02:20:43 2009
>> Local ID 2ada4c61-64cb-40d7-8268-83488b12426e
>> Line Numbers
>>
>> Raw Audit Messages
>>
>> node=coyote.coyote.den type=AVC msg=audit(1236237643.658:745): avc:
>> denied { append } for pid=8712 comm="procmail"
>> path="/var/log/fetchmail.log" dev=sda3 ino=23527557
>> scontext=system_u:system_r:procmail_t:s0
>> tcontext=system_u:object_r:var_log_t:s0 tclass=file
>>
>> node=coyote.coyote.den type=SYSCALL msg=audit(1236237643.658:745):
>> arch=40000003 syscall=11 success=yes exit=0 a0=8941670 a1=8941748
>> a2=8940af8 a3=0 items=0 ppid=2784 pid=8712 auid=4294967295 uid=501 gid=501
>> euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none)
>> ses=4294967295 comm="procmail" exe="/usr/bin/procmail"
>> subj=system_u:system_r:procmail_t:s0 key=(null)
>>
>> Thanks Guys.
>
>Is this a fetchmail log or a procmail log? What do you expect to get
>logged here?
fetchmails normal activities
>
>I guess you're running fetchmail in daemon mode with procmail as local
>delivery agent?
Correct.
>
>See if this helps:
>
># semanage fcontext -a -t procmail_log_t '/var/log/fetchmail\.log'
># restorecon -v /var/log/fetchmail.log
>
>Paul.
I did the restorecon -v thing on the two logs and that seems to have satisfied
setroubleshoot. For the nonce, I have had to restart it twice since rebooting
last night. I wonder if the f10 upgrade from f8 removed some stuff I had in
logrotate to address that?
Here are the messages snip surrounding the last failure:
Mar 5 02:28:31 coyote setroubleshoot: [program.ERROR] audit event#012node=coyote.coyote.den type=AVC
msg=audit(1236238110.422:761): avc: denied { signull } for pid=8602 comm="setroubleshootd"
scontext=unconfined_u:unconfined_r:setroubleshootd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 tclass=process#012#012node=coyote.coyote.den type=SYSCALL msg=audit(1236238110.422:761):
arch=40000003 syscall=37 success=yes exit=0 a0=1027 a1=0 a2=b7ab8a28 a3=1027 items=0 ppid=1 pid=8602 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="setroubleshootd" exe="/usr/bin/python"
subj=unconfined_u:unconfined_r:setroubleshootd_t:s0 key=(null)
Mar 5 08:29:46 coyote setroubleshoot: [rpc.ERROR] attempt to open server connection failed: Connection refused
Mar 5 08:30:50 coyote setroubleshoot: [server.ERROR] cannot start systen DBus service:
org.freedesktop.DBus.Error.AccessDenied: An SELinx policy prevents this sender from sending this message to this
recipient (rejected message had interface "org.freedesktop.DBus" member "ello" error name "(unset)" destination
"org.freedesktop.DBus")
Mar 5 08:31:20 coyote kernel: [33498.076923] SELinux: Context unconfined_u:unconfined_r:setroubleshootd_t:s0-
s0:c0.c1023 would be invald if enforcing
Chuckle, note miss-spelling above. :)
In those cases where I have restarted setroubleshoot, it always reports a
failure of the stop action only. Is the above enough to determine an exit
reason. In one case earlier, it said "exiting to prevent recursion"
As for the logging fsckups, I have now added a few lines to /etc/logrotate.d/mail,
as follows.
=================
# Logrotate file for fetchmail.log and procmail.log
/var/log/fetchmail.log {
missingok
compress
notifempty
weekly
size=1000k
rotate 5
copytruncate
create 0600 gene gene
prerotate
/usr/bin/killall fetchmail
sleep 1
endscript
postrotate
chown gene:gene /var/log/fetchmail.log
restorecon -v /var/log/fetchmail.log <-new
echo "log rotated on "date -u >>var/log/fetchmail.log
su gene -c "/usr/bin/fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
endscript
}
/var/log/procmail.log {
missingok
compress
notifempty
weekly
size=1000k
rotate 5
copytruncate
create 0600 gene gene
postrotate
restorecon -v /var/log/procmail.log <-new
echo "log rotated on "date -u >>/var/log/procmail.log
endscript
}
===============================
logrotates actions have consistently been a PIMA here. Humm, in fact since
those two files are 0600 gene gene, should I do an "su gene -c" wrapper on
those two restorecon lines?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
For large values of one, one equals two, for small values of two.
More information about the fedora-selinux-list
mailing list