Re: Rebooted, permissive, setroubleshooter going nuts.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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@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.



--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux