On Mon, 2009-12-07 at 23:36 +0100, Dominick Grift wrote:
On Mon, Dec 07, 2009 at 10:34:21PM +0000, Arthur Dent wrote:
> On Mon, 2009-12-07 at 23:17 +0100, Dominick Grift wrote:
> > On Mon, Dec 07, 2009 at 10:11:46PM +0000, Arthur Dent wrote:
> > > On Mon, 2009-12-07 at 12:49 +0100, Dominick Grift wrote:
> > > > On Sun, Dec 06, 2009 at 09:44:21PM +0000, 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
> > > >
> > > > You are using old policy.
> > >
> > > Am I?
> > > # rpm -q selinux-policy selinux-policy-targeted
> > > selinux-policy-3.6.12-88.fc11.noarch
> > > selinux-policy-targeted-3.6.12-88.fc11.noarch
> > >
> > >
> > > > [root@localhost ~]# semanage fcontext -l | grep fail2ban
> > > > /etc/rc\.d/init\.d/fail2ban regular file
system_u:object_r:fail2ban_initrc_exec_t:s0
> > > > /usr/bin/fail2ban regular file
system_u:object_r:fail2ban_exec_t:s0
> > > > /usr/bin/fail2ban-server regular file
system_u:object_r:fail2ban_exec_t:s0
> > > > /var/lib/fail2ban(/.*)? all files
system_u:object_r:fail2ban_var_lib_t:s0
> > > > /var/log/fail2ban\.log regular file
system_u:object_r:fail2ban_log_t:s0
> > > > /var/run/fail2ban.* all files
system_u:object_r:fail2ban_var_run_t:s0
> > >
> > > # semanage fcontext -l | grep fail2ban
> > > /etc/rc\.d/init\.d/fail2ban regular file
system_u:object_r:fail2ban_initrc_exec_t:s0
> > > /usr/bin/fail2ban regular file
system_u:object_r:fail2ban_exec_t:s0
> > > /usr/bin/fail2ban-server regular file
system_u:object_r:fail2ban_exec_t:s0
> > > /var/lib/fail2ban(/.*)? all files
system_u:object_r:fail2ban_var_lib_t:s0
> > > /var/log/fail2ban\.log regular file
system_u:object_r:fail2ban_log_t:s0
> > > /var/run/fail2ban.* all files
system_u:object_r:fail2ban_var_run_t:s0
> > >
> > > I may be wrong, but to me my results look the same?
> >
> > They look the same indeed. question remains, why does fail2ban-server runs in
the init script domain?
> >
> > matchpathcon /usr/bin/fail2ban-server
> >
> > ( could it be that the file is mislabeled? )
>
> # matchpathcon /usr/bin/fail2ban-server
> /usr/bin/fail2ban-server system_u:object_r:fail2ban_exec_t:s0
>
> Is that what you would expect to see?
yes, now the question is, is the path labeled the way it should be:
ls -alZ /usr/bin/fail2ban-server
# ls -alZ /usr/bin/fail2ban-server
-rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/bin/fail2ban-server
Hmmmm...
# restorecon -v /usr/bin/fail2ban-server
restorecon reset /usr/bin/fail2ban-server context
unconfined_u:object_r:bin_t:s0->system_u:object_r:fail2ban_exec_t:s0
# ls -alZ /usr/bin/fail2ban-server
-rwxr-xr-x. root root system_u:object_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server
Ahhh...
Is that more like it?
Thanks again!