Logrotate frustration

[Arthur Dent]

Hello all,

Its seems that almost every week logrotate is throwing up a new AVC. I
have an almost vanilla F11 install with most packages installed via yum
and yet I keep getting these. Each time I audit2allow and build a new
policy. My "mylogr.te" is now at version 7. Am I missing a bool or is
there something else I'm lacking?

Here is the latest version of my policy:


===============8<==================================================

module mylogr 11.1.7;

require {
	type mail_spool_t;
	type logrotate_t;
	type fail2ban_var_run_t;
	type initrc_t;
	type squid_log_t;
	class dir {read open write remove_name};
	class file { getattr read write open};
	class file setattr;
	class sock_file write;
        class unix_stream_socket connectto;
	class lnk_file rename;
}

#============= logrotate_t ==============
allow logrotate_t mail_spool_t:file { getattr read write open };
allow logrotate_t mail_spool_t:dir { read open write remove_name};
allow logrotate_t mail_spool_t:file setattr;
allow logrotate_t fail2ban_var_run_t:sock_file write;
allow logrotate_t initrc_t:unix_stream_socket connectto;
allow logrotate_t squid_log_t:lnk_file rename;

===============8<==================================================


This was today's AVC that necessitated the inclusion of the squid stuff:

===============8<==================================================
Raw Audit Messages :

node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for
pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195
scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003
syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300
pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
===============8<==================================================

[Justin P. Mattock]

On 12/06/09 01:38, Arthur Dent wrote:
>  Hello all,
>
>  Its seems that almost every week logrotate is throwing up a new AVC. I
>  have an almost vanilla F11 install with most packages installed via yum
>  and yet I keep getting these. Each time I audit2allow and build a new
>  policy. My "mylogr.te" is now at version 7. Am I missing a bool or is
>  there something else I'm lacking?
>
>  Here is the latest version of my policy:
>
>
>  ===============8<==================================================
>
>  module mylogr 11.1.7;
>
>  require {
>  	type mail_spool_t;
>  	type logrotate_t;
>  	type fail2ban_var_run_t;
>  	type initrc_t;
>  	type squid_log_t;
>  	class dir {read open write remove_name};
>  	class file { getattr read write open};
>  	class file setattr;
>  	class sock_file write;
>           class unix_stream_socket connectto;
>  	class lnk_file rename;
>  }
>
>  #============= logrotate_t ==============
>  allow logrotate_t mail_spool_t:file { getattr read write open };
>  allow logrotate_t mail_spool_t:dir { read open write remove_name};
>  allow logrotate_t mail_spool_t:file setattr;
>  allow logrotate_t fail2ban_var_run_t:sock_file write;
>  allow logrotate_t initrc_t:unix_stream_socket connectto;
>  allow logrotate_t squid_log_t:lnk_file rename;
>
>  ===============8<==================================================
>
>
>  This was today's AVC that necessitated the inclusion of the squid stuff:
>
>  ===============8<==================================================
>  Raw Audit Messages :
>
>  node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for
> pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195
> scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file
>  node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003
> syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300
> pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
> subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
>  ===============8<==================================================
>
>
>
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
I dont use logrotate over here(not sure of the label),
but looking at the avc's you supplied
seems it's a label issue.
(but correct me if I'm wrong);

Justin P. Mattock

[Dominick Grift]

On Sun, Dec 06, 2009 at 09:38:32AM +0000, Arthur Dent wrote:
>  Hello all,
>  
>  Its seems that almost every week logrotate is throwing up a new AVC. I
>  have an almost vanilla F11 install with most packages installed via yum
>  and yet I keep getting these. Each time I audit2allow and build a new
>  policy. My "mylogr.te" is now at version 7. Am I missing a bool or is
>  there something else I'm lacking?
>  
>  Here is the latest version of my policy:
>  
>  
>  ===============8<==================================================
>  
>  module mylogr 11.1.7;
>  
>  require {
>  	type mail_spool_t;
>  	type logrotate_t;
>  	type fail2ban_var_run_t;
>  	type initrc_t;
>  	type squid_log_t;
>  	class dir {read open write remove_name};
>  	class file { getattr read write open};
>  	class file setattr;
>  	class sock_file write;
>          class unix_stream_socket connectto;
>  	class lnk_file rename;
>  }
>  
>  #============= logrotate_t ==============
>  allow logrotate_t mail_spool_t:file { getattr read write open };
>  allow logrotate_t mail_spool_t:dir { read open write remove_name};
>  allow logrotate_t mail_spool_t:file setattr;
>  allow logrotate_t fail2ban_var_run_t:sock_file write;
>  allow logrotate_t initrc_t:unix_stream_socket connectto;
>  allow logrotate_t squid_log_t:lnk_file rename;
>  
>  ===============8<==================================================
>  
>  
>  This was today's AVC that necessitated the inclusion of the squid stuff:
>  
>  ===============8<==================================================
>  Raw Audit Messages :
>  
>  node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for
> pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195
> scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
>  node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003
> syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300
> pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
> subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
>  ===============8<================================================== 

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.


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Arthur Dent]

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

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<====================================================

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

Logrotate frustration - Selinux & Fail2Ban

[Dominick Grift]

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.

[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

But anyways with regard to SELinux issues: SELinux is a framework that lets you configure
the access that various processes have.
It just like iptables/netfilter where a particular port is not open. The netfilter
framework allows you to open it and the iptables frontend is a way to implement it.

No policy is ever perfect. So for professionals it is a good idea to just learn how to
manage an SELinux environment.

One thing to keep in mind is that processes running initrc_r do not have policy (in your
case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it
is encourage to confine these init daemons first.

Writing/implementing policy for a init daemon is not particularly hard and you do not have
to be a programmer to do so. 

With regard to fail2ban-server, you could start by trying to label the fail2ban executable
(/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext -a -t
fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server). This
should atleast get the fail2ban-server process out of the initrc_t domain and into the
fail2ban domain. From there on, youre on the right track. 

As for ddclient, gam_server and clamd it may require that you write a policy from scratch.
Also usually not hard to do. In a nutshell:

1. create a type for the process
2. create a type for the executable file
3. declare the two types init_daemon_domain().
4. label the executable file with the type you declared executable file.
5. start service (if needed in permissive mode during policy development stage) and see
whether the process runs with the declared type for the process.
6. use ausearch/audit2allow to write rule that define how you process type can interact
with other types.
7. make sure that interacting with type initrc_t means its trying to interact with a
process that is not confined (does not have policy yet)

after that, its just the five golden rules i mentioned in a previous post. 

1. make sure parties in an interaction have the expected type.
2. make sure you check for any booleans/custom types that may provide the access it
needs.
3. make sure you app is configured properly.
4. make sure you dont allow access that your app needs because it has a bug.
5. implement policy.

>  
>  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<====================================================
>  
>  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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Arthur Dent]

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?

>  
>  But anyways with regard to SELinux issues: SELinux is a framework that lets you configure
> the access that various processes have.
>  It just like iptables/netfilter where a particular port is not open. The netfilter
> framework allows you to open it and the iptables frontend is a way to implement it.
>  
>  No policy is ever perfect. So for professionals it is a good idea to just learn how to
> manage an SELinux environment.
>  
>  One thing to keep in mind is that processes running initrc_r do not have policy (in your
> case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable way it
> is encourage to confine these init daemons first.
>  
>  Writing/implementing policy for a init daemon is not particularly hard and you do not
> have to be a programmer to do so. 
>  
>  With regard to fail2ban-server, you could start by trying to label the fail2ban
> executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext
> -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server).
> This should atleast get the fail2ban-server process out of the initrc_t domain and into
> the fail2ban domain. From there on, youre on the right track.  
Do I still need to do this given the results of my semanage command
above?

If not, why should I need all the rules in my policy?

Actually - I may answer that myself. I keep up to date with selinux
policies using yum. On the other hand, I create local policies each time
an AVC rears its head, but what I DON'T do - and perhaps I should - is
revisit my local rules each time a new policy is issued. I guess I just
add and add and add my rules as they are needed. This means that my
local policy only ever grows. I'm afraid I don't have the detailed
understanding (or the time) to investigate the effects of each new
policy...

Should I perhaps just remove my "myfail2ban" policy and see what AVCs
arise?

What I tend to do is to leave my policies grow this way until a new
version of Fedora is released - I usually upgrade during my Christmas
and summer holidays - and start a new policy from scratch then (this
explains the naming convention I use "myfail2ban 11.1.3" is the third
minor revision of the second major revision of my fail2ban policy on F11
- When I uprade to F12 I will start with "myfail2ban 12.0.1")


>  As for ddclient, gam_server and clamd it may require that you write a
> policy from scratch. Also usually not hard to do. In a nutshell:
>  
>  1. create a type for the process
>  2. create a type for the executable file
>  3. declare the two types init_daemon_domain().
>  4. label the executable file with the type you declared executable file.
>  5. start service (if needed in permissive mode during policy development stage) and see
> whether the process runs with the declared type for the process.
>  6. use ausearch/audit2allow to write rule that define how you process type can interact
> with other types.
>  7. make sure that interacting with type initrc_t means its trying to interact with a
> process that is not confined (does not have policy yet) 
This is very helpful advice. Thank you.

However, should I need to do this? ddclient was installed using yum -
surely the package maintainer should have done this?

It's true though that gam_server came with fail2ban and I installed that
from source (I think I need to look at that - especially given Miroslav
Grepl's post below.

Clamd is also installed from source, but surely, as this is an
application in such a widespread use, should it not be included in
selinux-policy-targeted?


>  after that, its just the five golden rules i mentioned in a previous
> post. 
>  
>  1. make sure parties in an interaction have the expected type.
>  2. make sure you check for any booleans/custom types that may provide the access it
> needs.
>  3. make sure you app is configured properly.
>  4. make sure you dont allow access that your app needs because it has a bug.
>  5. implement policy.
>  
>  > 
>  > 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<====================================================
>  > 
>  > 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.
>  >  
Thanks again for your help.

I'm going to try to spend some time looking into these issues.

Best regards

Mark

Logrotate frustration - Selinux & Fail2Ban

[Dominick Grift]

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? )
>  
>  > 
>  > But anyways with regard to SELinux issues: SELinux is a framework that lets you
> configure the access that various processes have.
>  > It just like iptables/netfilter where a particular port is not open. The netfilter
> framework allows you to open it and the iptables frontend is a way to implement it.
>  > 
>  > No policy is ever perfect. So for professionals it is a good idea to just learn how
> to manage an SELinux environment.
>  > 
>  > One thing to keep in mind is that processes running initrc_r do not have policy (in
> your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable
> way it is encourage to confine these init daemons first.
>  > 
>  > Writing/implementing policy for a init daemon is not particularly hard and you do
> not have to be a programmer to do so. 
>  > 
>  > With regard to fail2ban-server, you could start by trying to label the fail2ban
> executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext
> -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server).
> This should atleast get the fail2ban-server process out of the initrc_t domain and into
> the fail2ban domain. From there on, youre on the right track. 
>  
>  Do I still need to do this given the results of my semanage command
>  above?
>  
>  If not, why should I need all the rules in my policy?
>  
>  Actually - I may answer that myself. I keep up to date with selinux
>  policies using yum. On the other hand, I create local policies each time
>  an AVC rears its head, but what I DON'T do - and perhaps I should - is
>  revisit my local rules each time a new policy is issued. I guess I just
>  add and add and add my rules as they are needed. This means that my
>  local policy only ever grows. I'm afraid I don't have the detailed
>  understanding (or the time) to investigate the effects of each new
>  policy...
>  
>  Should I perhaps just remove my "myfail2ban" policy and see what AVCs
>  arise?
>  
>  What I tend to do is to leave my policies grow this way until a new
>  version of Fedora is released - I usually upgrade during my Christmas
>  and summer holidays - and start a new policy from scratch then (this
>  explains the naming convention I use "myfail2ban 11.1.3" is the third
>  minor revision of the second major revision of my fail2ban policy on F11
>  - When I uprade to F12 I will start with "myfail2ban 12.0.1")
>  
>  
>  > As for ddclient, gam_server and clamd it may require that you write a policy from
> scratch. Also usually not hard to do. In a nutshell:
>  > 
>  > 1. create a type for the process
>  > 2. create a type for the executable file
>  > 3. declare the two types init_daemon_domain().
>  > 4. label the executable file with the type you declared executable file.
>  > 5. start service (if needed in permissive mode during policy development stage) and
> see whether the process runs with the declared type for the process.
>  > 6. use ausearch/audit2allow to write rule that define how you process type can
> interact with other types.
>  > 7. make sure that interacting with type initrc_t means its trying to interact with a
> process that is not confined (does not have policy yet)
>  
>  This is very helpful advice. Thank you.
>  
>  However, should I need to do this? ddclient was installed using yum -
>  surely the package maintainer should have done this?
>  
>  It's true though that gam_server came with fail2ban and I installed that
>  from source (I think I need to look at that - especially given Miroslav
>  Grepl's post below.
>  
>  Clamd is also installed from source, but surely, as this is an
>  application in such a widespread use, should it not be included in
>  selinux-policy-targeted?
>  
>  
>  > after that, its just the five golden rules i mentioned in a previous post. 
>  > 
>  > 1. make sure parties in an interaction have the expected type.
>  > 2. make sure you check for any booleans/custom types that may provide the access it
> needs.
>  > 3. make sure you app is configured properly.
>  > 4. make sure you dont allow access that your app needs because it has a bug.
>  > 5. implement policy.
>  > 
>  > > 
>  > > 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<====================================================
>  > > 
>  > > 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.
>  > > 
>  
>  Thanks again for your help.
>  
>  I'm going to try to spend some time looking into these issues.
>  
>  Best regards
>  
>  Mark
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Arthur Dent]

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?

Thanks for your help - much appreciated...

Mark

Logrotate frustration - Selinux & Fail2Ban

[Dominick Grift]

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


>  
>  Thanks for your help - much appreciated...
>  
>  Mark
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Arthur Dent]

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!

Logrotate frustration - Selinux & Fail2Ban

[Dominick Grift]

On Mon, Dec 07, 2009 at 10:44:15PM +0000, Arthur Dent wrote:
>  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? 
Yes that should get you atleast a little closer. I am wondering what else may be
mislabeled on your system.

maybe a relabel/fixfiles restore is in order...

>  
>  Thanks again!
>  
>  
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Selinux & Fail2Ban

[Arthur Dent]

On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote:

>  > > > > > > > [Snip] 
>  > > > 
>  > > > # 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?
>  
>  Yes that should get you atleast a little closer. I am wondering what else may be
> mislabeled on your system.
>  
>  maybe a relabel/fixfiles restore is in order... 
Yes. Good advice.

As it happens there was a new selinux policy available today (using yum
update):
# rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.6.12-91.fc11.noarch
selinux-policy-targeted-3.6.12-91.fc11.noarch


I removed two of my local policies (log rotation and fail2ban) and put
selinux into permissive mode.

Having updated I did a "touch /.autorelabel; reboot"

Following your 7 point plan I believe I am now at stage 6?
{
1) I believe there is a type created for the process? (fail2ban_exec)
2) I believe there is a type for the executable file (fail2ban_exec)
3) declare the two types init_daemon_domain(). (Not sure about this)
4) The executable file is labelled with the type fail2ban_exec
5) I have started the service (in permissive mode).
}

I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule.
(Copies of the AVCs below)

So - point 6: Using audit2allow I get this:

=================8<============================================

module myfail2ban 11.2.1;

require {
	type iptables_t;
	type system_mail_t;
	type fail2ban_t;
	class unix_stream_socket { read write };
}

#============= iptables_t ==============
allow iptables_t fail2ban_t:unix_stream_socket { read write };

#============= system_mail_t ==============
allow system_mail_t fail2ban_t:unix_stream_socket { read write };

=================8<============================================

So what do you think?

Am I on the right track?

Thanks again for all your help.

Mark


AVCs (I think a couple may be duplicates - I'm running in permissive
mode):

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for
pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217
scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11
success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="iptables" exe="/sbin/iptables"
subj=system_u:system_r:iptables_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for
pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217
scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11
success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none)
ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=system_u:system_r:system_mail_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write } for
pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217
scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11
success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="iptables" exe="/sbin/iptables"
subj=system_u:system_r:iptables_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write } for
pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217
scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11
success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="iptables" exe="/sbin/iptables"
subj=system_u:system_r:iptables_t:s0 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write } for
pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217
scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket 
node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11
success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none)
ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=system_u:system_r:system_mail_t:s0 key=(null)

Selinux & Fail2Ban

[Dominick Grift]

On Tue, Dec 08, 2009 at 08:43:32PM +0000, Arthur Dent wrote:
>  On Mon, 2009-12-07 at 23:51 +0100, Dominick Grift wrote:
>  
>  > > > > > > > > [Snip]
>  
>  > > > > 
>  > > > > # 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?
>  > 
>  > Yes that should get you atleast a little closer. I am wondering what else may be
> mislabeled on your system.
>  > 
>  > maybe a relabel/fixfiles restore is in order...
>  
>  Yes. Good advice.
>  
>  As it happens there was a new selinux policy available today (using yum
>  update):
>  # rpm -q selinux-policy selinux-policy-targeted
>  selinux-policy-3.6.12-91.fc11.noarch
>  selinux-policy-targeted-3.6.12-91.fc11.noarch
>  
>  
>  I removed two of my local policies (log rotation and fail2ban) and put
>  selinux into permissive mode.
>  
>  Having updated I did a "touch /.autorelabel; reboot"
>  
>  Following your 7 point plan I believe I am now at stage 6?
>  {
>  1) I believe there is a type created for the process? (fail2ban_exec)
>  2) I believe there is a type for the executable file (fail2ban_exec)
>  3) declare the two types init_daemon_domain(). (Not sure about this)
>  4) The executable file is labelled with the type fail2ban_exec
>  5) I have started the service (in permissive mode).
>  }
>  
>  I got 5 AVCs. 2 on startup and 3 when fail2ban actually hit on a rule.
>  (Copies of the AVCs below)
>  
>  So - point 6: Using audit2allow I get this:
>  
>  =================8<============================================
>  
>  module myfail2ban 11.2.1;
>  
>  require {
>  	type iptables_t;
>  	type system_mail_t;
>  	type fail2ban_t;
>  	class unix_stream_socket { read write };
>  }
>  
>  #============= iptables_t ==============
>  allow iptables_t fail2ban_t:unix_stream_socket { read write };
>  
>  #============= system_mail_t ==============
>  allow system_mail_t fail2ban_t:unix_stream_socket { read write };
>  
>  =================8<============================================
>  
>  So what do you think?
>  
>  Am I on the right track? 
Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };", signals
a leaked file descriptor on fail2ban. This issue is known. You can ignore those avc
denials and/or silence them:

echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
echo "optional_policy(\`" >> myfail2ban.te;
echo "gen_require(\`" >> myfail2ban.te;
echo "attribute domain;" >> myfail2ban.te;
echo "type fail2ban_t;" >> myfail2ban.te;
echo "\')" >> myfail2ban.te;
echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >>
myfail2ban.te;
echo "\')" >> myfail2ban.te;

make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
sudo semodule -i myfail2ban.pp


>  
>  Thanks again for all your help.
>  
>  Mark
>  
>  
>  AVCs (I think a couple may be duplicates - I'm running in permissive
>  mode):
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1260298720.4:21): avc: denied { read write } for
> pid=1907 comm="iptables" path="socket:[16217]" dev=sockfs ino=16217
> scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
> tclass=unix_stream_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1260298720.4:21): arch=40000003 syscall=11
> success=yes exit=0 a0=8a1a250 a1=8a1a460 a2=8a19738 a3=8a1a460 items=0 ppid=1906 pid=1907
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="iptables" exe="/sbin/iptables"
> subj=system_u:system_r:iptables_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1260298720.169:22): avc: denied { read write } for
> pid=1921 comm="sendmail" path="socket:[16217]" dev=sockfs ino=16217
> scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0
> tclass=unix_stream_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1260298720.169:22): arch=40000003 syscall=11
> success=yes exit=0 a0=85867d0 a1=8587798 a2=8587670 a3=8587798 items=0 ppid=1919 pid=1921
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none)
> ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
> subj=system_u:system_r:system_mail_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1260301404.622:121): avc: denied { read write }
> for pid=2799 comm="iptables" path="socket:[16217]" dev=sockfs
> ino=16217 scontext=system_u:system_r:iptables_t:s0
> tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1260301404.622:121): arch=40000003 syscall=11
> success=yes exit=0 a0=88b13e0 a1=88b1618 a2=88b06f8 a3=88b1618 items=0 ppid=2798 pid=2799
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="iptables" exe="/sbin/iptables"
> subj=system_u:system_r:iptables_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1260301405.169:122): avc: denied { read write }
> for pid=2804 comm="iptables" path="socket:[16217]" dev=sockfs
> ino=16217 scontext=system_u:system_r:iptables_t:s0
> tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1260301405.169:122): arch=40000003 syscall=11
> success=yes exit=0 a0=96e3418 a1=96e3718 a2=96e2700 a3=96e3718 items=0 ppid=1901 pid=2804
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=4294967295 comm="iptables" exe="/sbin/iptables"
> subj=system_u:system_r:iptables_t:s0 key=(null) 
>  
>  Raw Audit Messages :
>  
>  node=troodos.org.uk type=AVC msg=audit(1260301405.212:123): avc: denied { read write }
> for pid=2811 comm="sendmail" path="socket:[16217]" dev=sockfs
> ino=16217 scontext=system_u:system_r:system_mail_t:s0
> tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket 
>  node=troodos.org.uk type=SYSCALL msg=audit(1260301405.212:123): arch=40000003 syscall=11
> success=yes exit=0 a0=a119518 a1=a119a48 a2=a119750 a3=a119a48 items=0 ppid=2807 pid=2811
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none)
> ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
> subj=system_u:system_r:system_mail_t:s0 key=(null) 
>  
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Selinux & Fail2Ban

[Arthur Dent]

On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote:

>  > So what do you think?
>  > 
>  > Am I on the right track?
>  
>  Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };",
> signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those
> avc denials and/or silence them: 
What exactly *is* a "leaked file descriptor"?


>  echo "policy_module(myfail2ban, 1.0.0)" >
> myfail2ban.te;
>  echo "optional_policy(\`" >> myfail2ban.te;
>  echo "gen_require(\`" >> myfail2ban.te;
>  echo "attribute domain;" >> myfail2ban.te;
>  echo "type fail2ban_t;" >> myfail2ban.te;
>  echo "\')" >> myfail2ban.te;
>  echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };" >>
> myfail2ban.te;
>  echo "\')" >> myfail2ban.te; 
OK - Thanks for this. It's not the way I'm used to generating local
policies and I think there may be an error? Once all the lines are
echo'd into myfail2ban.te this is what I get:
# cat myfail2ban.te

policy_module(myfail2ban, 11.2.1)
optional_policy(`
gen_require(`
attribute domain;
type fail2ban_t;
\')
dontaudit domain fail2ban_t:unix_stream_socket { read write };
\')

Which won't compile: 
>  make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
>  sudo semodule -i myfail2ban.pp 
Gives:

# make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
Compiling targeted myfail2ban module
/usr/bin/checkmodule:  loading policy configuration from
tmp/myfail2ban.tmp
myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
line
3204:
\
#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
line
3214:
\
#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
line
3204:
\
#line 2
myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
line
3214:
\
#line 2
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to
tmp/myfail2ban.mod
Creating targeted myfail2ban.pp policy package
rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod


I'm not exactly sure what you had in mind otherwise I would edit it to
work...


But thanks again. I do appreciate your help!

Mark

Selinux & Fail2Ban

[Dominick Grift]

On Tue, Dec 08, 2009 at 09:15:48PM +0000, Arthur Dent wrote:
>  On Tue, 2009-12-08 at 21:57 +0100, Dominick Grift wrote:
>  
>  > > So what do you think?
>  > > 
>  > > Am I on the right track?
>  > 
>  > Yes "allow system_mail_t fail2ban_t:unix_stream_socket { read write };",
> signals a leaked file descriptor on fail2ban. This issue is known. You can ignore those
> avc denials and/or silence them:
>  
>  What exactly *is* a "leaked file descriptor"?
>  
>  
>  > echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
>  > echo "optional_policy(\`" >> myfail2ban.te;
>  > echo "gen_require(\`" >> myfail2ban.te;
>  > echo "attribute domain;" >> myfail2ban.te;
>  > echo "type fail2ban_t;" >> myfail2ban.te;
>  > echo "\')" >> myfail2ban.te;
>  > echo "dontaudit domain fail2ban_t:unix_stream_socket { read write };"
> >> myfail2ban.te;
>  > echo "\')" >> myfail2ban.te;
>  
>  OK - Thanks for this. It's not the way I'm used to generating local
>  policies and I think there may be an error? Once all the lines are
>  echo'd into myfail2ban.te this is what I get:
>  # cat myfail2ban.te
>  
>  policy_module(myfail2ban, 11.2.1)
>  optional_policy(`
>  gen_require(`
>  attribute domain;
>  type fail2ban_t;
>  \')
>  dontaudit domain fail2ban_t:unix_stream_socket { read write };
>  \') 
Your myfail2ban.te file should look like this:

policy_module(myfail2ban, 11.2.1)
optional_policy(`
gen_require(`
attribute domain;
type fail2ban_t;
')
dontaudit domain fail2ban_t:unix_stream_socket { read write };
')

A leaked file descriptor is a programming error it is where the programmer forgot to close
a file descriptor (bug in fail2ban)

>  
>  Which won't compile: 
>  > make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
>  > sudo semodule -i myfail2ban.pp
>  Gives:
>  
>  # make -f /usr/share/selinux/devel/Makefile myfail2ban.pp
>  Compiling targeted myfail2ban module
>  /usr/bin/checkmodule:  loading policy configuration from
>  tmp/myfail2ban.tmp
>  myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
> line
>  3204:
>  \
>  #line 2
>  myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
> line
>  3214:
>  \
>  #line 2
>  myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
> line
>  3204:
>  \
>  #line 2
>  myfail2ban.te":2:WARNING 'unrecognized character' at token '\' on
> line
>  3214:
>  \
>  #line 2
>  /usr/bin/checkmodule:  policy configuration loaded
>  /usr/bin/checkmodule:  writing binary representation (version 10) to
>  tmp/myfail2ban.mod
>  Creating targeted myfail2ban.pp policy package
>  rm tmp/myfail2ban.mod.fc tmp/myfail2ban.mod
>  
>  
>  I'm not exactly sure what you had in mind otherwise I would edit it to
>  work...
>  
>  
>  But thanks again. I do appreciate your help!
>  
>  Mark
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Selinux & Fail2Ban

[Arthur Dent]

On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote:

>  
>  Your myfail2ban.te file should look like this:
>  
>  policy_module(myfail2ban, 11.2.1)
>  optional_policy(`
>  gen_require(`
>  attribute domain;
>  type fail2ban_t;
>  ')
>  dontaudit domain fail2ban_t:unix_stream_socket { read write };
>  ') 
That did it - Thanks!

>  A leaked file descriptor is a programming error it is where the
> programmer forgot to close a file descriptor (bug in fail2ban) 
How can I explain this to the f2b developers so that it can be fixed?

Thanks - yet again!

Mark

Selinux & Fail2Ban

[David P. Quigley]

On Tue, 2009-12-08 at 21:37 +0000, Arthur Dent wrote:
>  On Tue, 2009-12-08 at 22:24 +0100, Dominick Grift wrote:
>  
>  > 
>  > Your myfail2ban.te file should look like this:
>  > 
>  > policy_module(myfail2ban, 11.2.1)
>  > optional_policy(`
>  > gen_require(`
>  > attribute domain;
>  > type fail2ban_t;
>  > ')
>  > dontaudit domain fail2ban_t:unix_stream_socket { read write };
>  > ')
>  
>  That did it - Thanks!
>  
>  > A leaked file descriptor is a programming error it is where the programmer forgot to
> close a file descriptor (bug in fail2ban)
>  
>  How can I explain this to the f2b developers so that it can be fixed?
>   
So I have copied a small section from Dan Walsh's blog. Its a bit more
than forgetting to close a file descriptor. The problem is that by
default on exec the child process will inherit all file descriptors from
the parent except ones that are closed before exec or marked close on
exec with the fcntl listed below.

        One of the interesting things about SELinux is its use to
        discover bugs in other code. When I first started working with
        SELinux a few years ago, we started discovering a whole bunch of
        domains wanting to read and write system_u:object_r:initctl_t
        file. This is the context of the /dev/initctl device. After
        investigating for a while we found out something in the boot
        process was leaking an open file descriptor to /dev/initctl.
        This open file descriptor would allow a compromised application
        to change the run level of the system. Of course all of these
        AVC messages were being reported as bugs in SELinux, but really
        they were a serious bug in the boot process. Investigating this
        problem further I found that the default behavior of all file
        descriptors is to have them inherited over the fork/exec. You
        have to execute fcntl(fd, F_SETFD, FD_CLOEXEC); on all file
        descriptors that you do not want to be leaked. Needless to say,
        lots of programmers forget this and leaked file descriptors are
        quite common.
        
        Dan Walsh

>  Thanks - yet again!
>  
>  Mark
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Selinux & Fail2Ban

[Göran Uddeborg]

Arthur Dent:
>  How can I explain this to the f2b developers so that it can be fixed?
For your information: I filed a bug about it a little more than a year
ago:
http://sourceforge.net/tracker/?func=detail&atid=689044&aid=20865...

There hasn't been any action as far as I can tell.  But maybe you'll
have more luck if you do a new try now.

Selinux & Fail2Ban

[Daniel J Walsh]

On 12/09/2009 02:37 PM, Göran Uddeborg wrote:
>  Arthur Dent:
> > How can I explain this to the f2b developers so that it can be fixed?
>  
>  For your information: I filed a bug about it a little more than a year
>  ago:
>
> http://sourceforge.net/tracker/?func=detail&atid=689044&aid=20865...
>  
>  There hasn't been any action as far as I can tell.  But maybe you'll
>  have more luck if you do a new try now.
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>   
Fail2ban developers are well aware of this, they have been dealing with leaks for
a while

Logrotate frustration - Selinux & Fail2Ban

[Dominick Grift]

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?
>  
>  > 
>  > But anyways with regard to SELinux issues: SELinux is a framework that lets you
> configure the access that various processes have.
>  > It just like iptables/netfilter where a particular port is not open. The netfilter
> framework allows you to open it and the iptables frontend is a way to implement it.
>  > 
>  > No policy is ever perfect. So for professionals it is a good idea to just learn how
> to manage an SELinux environment.
>  > 
>  > One thing to keep in mind is that processes running initrc_r do not have policy (in
> your case ddclient, gameserver, clamd, and fail2ban-server). To fix this in a managable
> way it is encourage to confine these init daemons first.
>  > 
>  > Writing/implementing policy for a init daemon is not particularly hard and you do
> not have to be a programmer to do so. 
>  > 
>  > With regard to fail2ban-server, you could start by trying to label the fail2ban
> executable (/usr/bin/fail2ban-server) with the fail2ban executable type (semanage fcontext
> -a -t fail2ban_exec_t /usr/bin/fail2ban-server; restorecon -v /usr/bin/fail2ban-server).
> This should atleast get the fail2ban-server process out of the initrc_t domain and into
> the fail2ban domain. From there on, youre on the right track. 
>  
>  Do I still need to do this given the results of my semanage command
>  above? 
Well the specification for /usr/bin/fail2ban-server looks good. but the context in which
fail2ban-server is running does not correspond to the spec. So i suspect the file may be
mislabeled.

a restorecon -v /usr/bin/fail2ban-server would clear that up. The type of that location
should not be bin_t.
>  
>  If not, why should I need all the rules in my policy?
>  
>  Actually - I may answer that myself. I keep up to date with selinux
>  policies using yum. On the other hand, I create local policies each time
>  an AVC rears its head, but what I DON'T do - and perhaps I should - is
>  revisit my local rules each time a new policy is issued. I guess I just
>  add and add and add my rules as they are needed. This means that my
>  local policy only ever grows. I'm afraid I don't have the detailed
>  understanding (or the time) to investigate the effects of each new
>  policy...
>  
>  Should I perhaps just remove my "myfail2ban" policy and see what AVCs
>  arise? 
Well you can always try, given that you have the source policy, and given that you can
reinstall that if the avcs turn out to be identical 
programs evolve (fix bugs) policy should in my view evolve with the program.

>  
>  What I tend to do is to leave my policies grow this way until a new
>  version of Fedora is released - I usually upgrade during my Christmas
>  and summer holidays - and start a new policy from scratch then (this
>  explains the naming convention I use "myfail2ban 11.1.3" is the third
>  minor revision of the second major revision of my fail2ban policy on F11
>  - When I uprade to F12 I will start with "myfail2ban 12.0.1")
>  
>  
>  > As for ddclient, gam_server and clamd it may require that you write a policy from
> scratch. Also usually not hard to do. In a nutshell:
>  > 
>  > 1. create a type for the process
>  > 2. create a type for the executable file
>  > 3. declare the two types init_daemon_domain().
>  > 4. label the executable file with the type you declared executable file.
>  > 5. start service (if needed in permissive mode during policy development stage) and
> see whether the process runs with the declared type for the process.
>  > 6. use ausearch/audit2allow to write rule that define how you process type can
> interact with other types.
>  > 7. make sure that interacting with type initrc_t means its trying to interact with a
> process that is not confined (does not have policy yet)
>  
>  This is very helpful advice. Thank you.
>  
>  However, should I need to do this? ddclient was installed using yum - 
Not all everything has policy yet and package maintainers arent responsible for providing
selinux policy although it is a plus if they do provide policy for their package. It does
not change the fact that the selinux framework allows you to implement policy yourself.
>  surely the package maintainer should have done this?
>  
>  It's true though that gam_server came with fail2ban and I installed that
>  from source (I think I need to look at that - especially given Miroslav
>  Grepl's post below.
>  
>  Clamd is also installed from source, but surely, as this is an
>  application in such a widespread use, should it not be included in
>  selinux-policy-targeted? 
The problem is the path where clamd executable file is. There may be policy for clamd but
the policy expects the executable to be elsewhere. So if that is the case you could just
label the executable with the clamd executable type.

semanage fcontext -a -t clamd_exec_t /usr/local/sbin/clamd
restorecon -v /usr/local/sbin/clamd
ls -alZ /usr/local/sbin/clamd 
>  
>  
>  > after that, its just the five golden rules i mentioned in a previous post. 
>  > 
>  > 1. make sure parties in an interaction have the expected type.
>  > 2. make sure you check for any booleans/custom types that may provide the access it
> needs.
>  > 3. make sure you app is configured properly.
>  > 4. make sure you dont allow access that your app needs because it has a bug.
>  > 5. implement policy.
>  > 
>  > > 
>  > > 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<====================================================
>  > > 
>  > > 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.
>  > > 
>  
>  Thanks again for your help.
>  
>  I'm going to try to spend some time looking into these issues.
>  
>  Best regards
>  
>  Mark
>   


>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Miroslav Grepl]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Logrotate frustration - Selinux & Fail2Ban

[Arthur Dent]

On Mon, 2009-12-07 at 13:50 +0100, Miroslav Grepl wrote:
>  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
>   
# rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.6.12-88.fc11.noarch

# matchpathcon /usr/bin/fail2ban-server
/usr/bin/fail2ban-server	system_u:object_r:fail2ban_exec_t:s0


>  > 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 used to use the version of fail2ban from yum - but a recent perl
update caused a bug. To get the fixed version in a timely manner I had
to install F2B from source. I guess the rpm has now been updated and I
could go back to it...

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

[Daniel J Walsh]

On 12/06/2009 04:38 AM, Arthur Dent wrote:
>  Hello all,
>  
>  Its seems that almost every week logrotate is throwing up a new AVC. I
>  have an almost vanilla F11 install with most packages installed via yum
>  and yet I keep getting these. Each time I audit2allow and build a new
>  policy. My "mylogr.te" is now at version 7. Am I missing a bool or is
>  there something else I'm lacking?
>  
>  Here is the latest version of my policy:
>  
>  
>  ===============8<==================================================
>  
>  module mylogr 11.1.7;
>  
>  require {
>  	type mail_spool_t;
>  	type logrotate_t;
>  	type fail2ban_var_run_t;
>  	type initrc_t;
>  	type squid_log_t;
>  	class dir {read open write remove_name};
>  	class file { getattr read write open};
>  	class file setattr;
>  	class sock_file write;
>          class unix_stream_socket connectto;
>  	class lnk_file rename;
>  }
>  
>  #============= logrotate_t ==============
>  allow logrotate_t mail_spool_t:file { getattr read write open };
>  allow logrotate_t mail_spool_t:dir { read open write remove_name};
>  allow logrotate_t mail_spool_t:file setattr;
>  allow logrotate_t fail2ban_var_run_t:sock_file write;
>  allow logrotate_t initrc_t:unix_stream_socket connectto;
>  allow logrotate_t squid_log_t:lnk_file rename;
>  
>  ===============8<==================================================
>  
>  
>  This was today's AVC that necessitated the inclusion of the squid stuff:
>  
>  ===============8<==================================================
>  Raw Audit Messages :
>  
>  node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename } for
> pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195
> scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
>  node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003
> syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300
> pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
> subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
>  ===============8<==================================================
>  
>  
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
I can allow logrotate
to manage log lnk_files, and allow it to write to the fail2ban socket.

Are you using a custom logrotate to rotate mail_spool?

Why is

[Arthur Dent]

On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote:
>  On 12/06/2009 04:38 AM, Arthur Dent wrote:
>  > Hello all,
>  > 
>  > Its seems that almost every week logrotate is throwing up a new AVC. I
>  > have an almost vanilla F11 install with most packages installed via yum
>  > and yet I keep getting these. Each time I audit2allow and build a new
>  > policy. My "mylogr.te" is now at version 7. Am I missing a bool or is
>  > there something else I'm lacking?
>  > 
>  > Here is the latest version of my policy:
>  > 
>  > 
>  > ===============8<==================================================
>  > 
>  > module mylogr 11.1.7;
>  > 
>  > require {
>  > 	type mail_spool_t;
>  > 	type logrotate_t;
>  > 	type fail2ban_var_run_t;
>  > 	type initrc_t;
>  > 	type squid_log_t;
>  > 	class dir {read open write remove_name};
>  > 	class file { getattr read write open};
>  > 	class file setattr;
>  > 	class sock_file write;
>  >         class unix_stream_socket connectto;
>  > 	class lnk_file rename;
>  > }
>  > 
>  > #============= logrotate_t ==============
>  > allow logrotate_t mail_spool_t:file { getattr read write open };
>  > allow logrotate_t mail_spool_t:dir { read open write remove_name};
>  > allow logrotate_t mail_spool_t:file setattr;
>  > allow logrotate_t fail2ban_var_run_t:sock_file write;
>  > allow logrotate_t initrc_t:unix_stream_socket connectto;
>  > allow logrotate_t squid_log_t:lnk_file rename;
>  > 
>  > ===============8<==================================================
>  > 
>  > 
>  > This was today's AVC that necessitated the inclusion of the squid stuff:
>  > 
>  > ===============8<==================================================
>  > Raw Audit Messages :
>  > 
>  > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied { rename
> } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5
> ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
>  > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041): arch=40000003
> syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0 ppid=12300
> pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
> subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
>  > ===============8<==================================================
>  > 
>  > 
>  > 
>  > --
>  > fedora-selinux-list mailing list
>  > fedora-selinux-list(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban
> socket.
>  
>  Are you using a custom logrotate to rotate mail_spool?
>  
>  Why is  
I think that my problem with mailspool/logrotate is that it relates to
my mail backup system in which procmail places a copy of every mail (in
mbox format) onto a separate partition on the same machine. This seemed
to cause labelling problems and we went round the houses on this issue a
while back ("Partitions Mounted by fstab" 5 March 2008 -
https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00030.html)

Thanks for your help - much appreciated...

Mark

[Arthur Dent]

On Mon, 2009-12-07 at 22:30 +0000, Arthur Dent wrote:
>  On Mon, 2009-12-07 at 16:24 -0500, Daniel J Walsh wrote:
>  > On 12/06/2009 04:38 AM, Arthur Dent wrote:
>  > > Hello all,
>  > > 
>  > > Its seems that almost every week logrotate is throwing up a new AVC. I
>  > > have an almost vanilla F11 install with most packages installed via yum
>  > > and yet I keep getting these. Each time I audit2allow and build a new
>  > > policy. My "mylogr.te" is now at version 7. Am I missing a bool or
> is
>  > > there something else I'm lacking?
>  > > 
>  > > Here is the latest version of my policy:
>  > > 
>  > > 
>  > > ===============8<==================================================
>  > > 
>  > > module mylogr 11.1.7;
>  > > 
>  > > require {
>  > > 	type mail_spool_t;
>  > > 	type logrotate_t;
>  > > 	type fail2ban_var_run_t;
>  > > 	type initrc_t;
>  > > 	type squid_log_t;
>  > > 	class dir {read open write remove_name};
>  > > 	class file { getattr read write open};
>  > > 	class file setattr;
>  > > 	class sock_file write;
>  > >         class unix_stream_socket connectto;
>  > > 	class lnk_file rename;
>  > > }
>  > > 
>  > > #============= logrotate_t ==============
>  > > allow logrotate_t mail_spool_t:file { getattr read write open };
>  > > allow logrotate_t mail_spool_t:dir { read open write remove_name};
>  > > allow logrotate_t mail_spool_t:file setattr;
>  > > allow logrotate_t fail2ban_var_run_t:sock_file write;
>  > > allow logrotate_t initrc_t:unix_stream_socket connectto;
>  > > allow logrotate_t squid_log_t:lnk_file rename;
>  > > 
>  > > ===============8<==================================================
>  > > 
>  > > 
>  > > This was today's AVC that necessitated the inclusion of the squid stuff:
>  > > 
>  > > ===============8<==================================================
>  > > Raw Audit Messages :
>  > > 
>  > > node=mydomain.org.uk type=AVC msg=audit(1260069452.494:45041): avc: denied {
> rename } for pid=12302 comm="logrotate" name="squidGuard.log" dev=sda5
> ino=387195 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
>  > > node=mydomain.org.uk type=SYSCALL msg=audit(1260069452.494:45041):
> arch=40000003 syscall=38 success=no exit=-13 a0=890b130 a1=8908760 a2=890b060 a3=0 items=0
> ppid=12300 pid=12302 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=2275 comm="logrotate" exe="/usr/sbin/logrotate"
> subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
>  > > ===============8<==================================================
>  > > 
>  > > 
>  > > 
>  > > --
>  > > fedora-selinux-list mailing list
>  > > fedora-selinux-list(a)redhat.com
>  > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  > I can allow logrotate to manage log lnk_files, and allow it to write to the fail2ban
> socket.
>  > 
>  > Are you using a custom logrotate to rotate mail_spool?
>  > 
>  > Why is 
>  
>  I think that my problem with mailspool/logrotate is that it relates to
>  my mail backup system in which procmail places a copy of every mail (in
>  mbox format) onto a separate partition on the same machine. This seemed
>  to cause labelling problems and we went round the houses on this issue a
>  while back ("Partitions Mounted by fstab" 5 March 2008 -
>  https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00030.html)
>  
>  Thanks for your help - much appreciated...
>  
>  Mark 
OK - Following another arm of this thread I have (last week) done a
complete relabel and removed my existing fail2ban and logrotate local
policies.

As a result of yesterday's weekly log rotate squid threw up another
couple of AVCs related to log_lnk (see below).

I have created another local policy but, do I understand you correctly
Daniel that you may include log_lnk in a future targeted policy?

Here is my new logrotate policy:

===============8<==================================================

module mylogr 11.2.2;

require {
        type mail_spool_t;
        type logrotate_t;
	type squid_log_t;
        class file getattr;
	class lnk_file { rename unlink };
}

#============= logrotate_t ==============
allow logrotate_t mail_spool_t:file getattr;
allow logrotate_t squid_log_t:lnk_file { rename unlink };

===============8<==================================================

Is this OK?

Thanks for any help or suggestions...

Mark

p.s.

Logrotate AVCs

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260331775.761:1220): avc: denied { getattr } for
pid=31349 comm="logrotate" path="/mnt/backup/mail/rawmail" dev=sda9
ino=2490369 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
tcontext=system_u:object_r:mail_spool_t:s0 tclass=file 
node=troodos.org.uk type=SYSCALL msg=audit(1260331775.761:1220): arch=40000003 syscall=196
success=yes exit=0 a0=9e59668 a1=bfd3e864 a2=bf5ff4 a3=1 items=0 ppid=31347 pid=31349
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=257
comm="logrotate" exe="/usr/sbin/logrotate"
subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) 

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260675470.813:43484): avc: denied { rename } for
pid=11490 comm="logrotate" name="squidGuard.log" dev=sda5 ino=387195
scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
node=troodos.org.uk type=SYSCALL msg=audit(1260675470.813:43484): arch=40000003 syscall=38
success=yes exit=0 a0=8295138 a1=8298f98 a2=8295068 a3=0 items=0 ppid=11488 pid=11490
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1554
comm="logrotate" exe="/usr/sbin/logrotate"
subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1260675471.68:43485): avc: denied { unlink } for
pid=11490 comm="logrotate" name="squidGuard.log.1" dev=sda5 ino=387195
scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
tcontext=system_u:object_r:squid_log_t:s0 tclass=lnk_file 
node=troodos.org.uk type=SYSCALL msg=audit(1260675471.68:43485): arch=40000003 syscall=10
success=yes exit=0 a0=8298f98 a1=bfbeffa8 a2=8298f98 a3=bfbeff70 items=0 ppid=11488
pid=11490 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=1554 comm="logrotate" exe="/usr/sbin/logrotate"
subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)