Rebooted, permissive, setroubleshooter going nuts.
Paul Howarth
paul at city-fan.org
Thu Mar 5 12:02:14 UTC 2009
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?
I guess you're running fetchmail in daemon mode with procmail as local
delivery agent?
See if this helps:
# semanage fcontext -a -t procmail_log_t '/var/log/fetchmail\.log'
# restorecon -v /var/log/fetchmail.log
Paul.
More information about the fedora-selinux-list
mailing list