Rebooted, permissive, setroubleshooter going nuts.
Miroslav Grepl
mgrepl at redhat.com
Thu Mar 5 14:29:02 UTC 2009
Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?
>>
>> 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>
> Currently f10 policy has
>
> ./policy/modules/services/mta.te:logging_append_all_logs(system_mail_t)
> ./policy/modules/system/init.te:logging_append_all_logs(initrc_t)
> ./policy/modules/system/init.te:logging_append_all_logs(daemon)
>
> I think it could be argued that we should allow all confined domains to
> append to any log file, since simple redirection of stdout causes the
> AVC in question. Being able to write to a log file allows a cracked
> program to erase the log contents. Being able to append to a log file
> means you could fill up the system with garbage or write something to a
> log file that would cause some other app or Human to do something bad.
>
> Fetchmail policy does not allow for the creation of a logfile right now.
> I guess the default is to write to syslog. We need to add a mechansim
> for fetchmail to create a fetchmail_log_t and allow procmail_t to append
> to it.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmv1JIACgkQrlYvE4MpobMVoQCbBguw0NgYBYr0X/6gfv5pqNXF
> IUQAoNW3KmkesnPbo5CcPaUxCofKvPeR
> =TiT3
> -----END PGP SIGNATURE-----
>
Ok, I will add this mechanism to the policy.
More information about the fedora-selinux-list
mailing list