Logrotate frustration - Selinux & Fail2Ban
Miroslav Grepl
mgrepl at redhat.com
Mon Dec 7 12:50:38 UTC 2009
On 12/06/2009 10:44 PM, Arthur Dent wrote:
> On Sun, 2009-12-06 at 12:59 +0100, Dominick Grift wrote:
>
>> On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote:
>>
>>>
> [Snip]
>
>
>> The rule with the initrc_t type is due to missing policy. It is encouraged to implement policy for all init daemons.
>>
>> With regard to the other rules you can, i guess, basically allow the access required,
>>
>> But always go through the checklist:
>>
>> 1. are the parties in an interaction labeled correctly? (matchpatchcon/restorecon/semanage/chcon)
>> 2. are there any booleans or types that facilitate a certain interaction? (audit2allow)
>> 3. is there a misconfiguration in some application? (see if a program should be able to do what it wants)
>> 3. is there a bug in some application? (is the denial due to a bug in an application?)
>> 4. is there a bug in the selinux policy? (missing policy to allow a certain interaction?)
>> 5. is it a break in attempt (is the application compromised.
>>
>> taking these 5 golden rules into concideration. i have some questions:
>>
>> allow logrotate_t fail2ban_var_run_t:sock_file write
>> - why would logrotate have to write to a fail2ban sock file? (this may be a bug in fail2ban, maybe leaked file descriptor. does this denial cause any loss in functionality? if not consider silently denying it)
>>
>> allow logrotate_t squid_log_t:lnk_file rename;
>> - why does squidgaurd, or whatever managed squid_log_t lnk_file, create a lnk_file in /var/log/... This is obviously not common behaviour afaik. That may be the reason why is denied.
>>
>> withregard to the rules with mail_spool_t type i would like to know if and why logrotate wants to rotate spool files. is this expeected behaviour of logrotate or are the mail_spool_t object mislabeled?
>>
>> so in conclusion the only denial that i am somewhat comfortable with is the squid link file denial. This may be some uncommon behaviour of squid/squidgaurd that selinux policy currently does not support (when confirmed that squidgaurd indeed creates a lnk file in /var/log for some reason , then implement policy to allow logrotate to rename the link (and what else it may need to do with the lnk_file.)
>>
>> See what runs initrc_t (ps auxZ) and consider writing policy for this init daemon. By implementing policy for init daemon you prtect the system plus you achive that confined domain do not have to interact with the unconfined initrc_t domain.
>>
> OK - I'm going to change the focus of this question slightly here.
>
> Many of my AVCs do in fact relate to Fail2Ban and in fact running ps
> auxZ shows the following:
>
> # ps auxZ | grep init
> system_u:system_r:init_t:s0 root 1 0.0 0.0 2008 164 ? Ss Dec02 0:03 /sbin/init
> system_u:system_r:initrc_t:s0 ddclient 1673 0.0 0.7 10228 2956 ? S Dec02 1:00 ddclient - sleeping for 130 seconds
> system_u:system_r:initrc_t:s0 root 1827 0.1 0.5 75940 2156 ? Sl Dec02 6:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -x
> system_u:system_r:initrc_t:s0 root 1830 0.0 0.0 2904 348 ? S Dec02 0:17 /usr/libexec/gam_server
> unconfined_u:system_r:initrc_t:s0 clamav 13149 0.3 28.8 220652 109928 ? Ssl 05:50 1:30 /usr/local/sbin/clamd
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 14886 1.0 0.1 4200 720 pts/0 S+ 12:08 0:00 grep init
>
>
Arthur,
what's your version of selinux-policy ?
# rpm -q selinux-policy selinux-policy-targeted
What is the output of the following command:
# matchpathcon /usr/bin/fail2ban-server
> My Fail2Ban policy has also grown over the months and now looks like
> this:
> ===============8<====================================================
> module myfail2ban 11.1.3;
>
> require {
> type iptables_t;
> type system_mail_t;
> type fail2ban_t;
> type usr_t;
> type syslogd_t;
> type sendmail_t;
> type initrc_t;
> class file read;
> class unix_stream_socket { read write };
> class unix_dgram_socket { read write sendto };
> }
>
> #============= fail2ban_t ==============
> allow fail2ban_t self:unix_dgram_socket write;
> allow fail2ban_t syslogd_t:unix_dgram_socket sendto;
>
> #============= iptables_t ==============
> allow iptables_t fail2ban_t:unix_stream_socket { read write };
> allow iptables_t fail2ban_t:unix_dgram_socket { read write };
> allow iptables_t initrc_t:unix_dgram_socket { read write };
>
> #============= system_mail_t ==============
> allow system_mail_t fail2ban_t:unix_stream_socket { read write };
> allow system_mail_t fail2ban_t:unix_dgram_socket { read write };
> allow system_mail_t usr_t:file read;
>
> #============= sendmail_t ==============
> allow sendmail_t initrc_t:unix_dgram_socket { read write };
>
> ===============8<====================================================
>
>
Actually fail2ban leaking file descriptors.
# rpm -q fail2ban
Also do not use gam_server with fail2ban, change it to polling mode please.
> I am concious that this is not ideal and so I have asked on the fail2ban
> list if someone with more technical expertise than me can help clean up
> fail2ban with respect to selinux.
>
> Fortunately Arturo "Buanzo" Busleiman, one of the developers, has
> offered to take a look at this. (I am also copying this email to the
> fail2ban list).
>
> I would very much appreciate it if Dominick, Daniel, and anyone else who
> can help, could liaise with Arturo so that this important security
> package could work cleanly with selinux.
>
> I will do what I can too - but I should just point out that I can just
> about spell "patch" and only if I'm really desperate would I ever try to
> apply one!
>
> Thanks in advance.
>
> Mark
>
>
>
>
>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20091207/bca4e1df/attachment.htm>
More information about the fedora-selinux-list
mailing list