FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 12-06-2009, 08:44 PM
Arthur Dent
 
Default Logrotate frustration - Selinux & Fail2Ban

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



--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 10:49 AM
Dominick Grift
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
/usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
/usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
/var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
/var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
/var/run/fail2ban.* all files system_ubject_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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 11:50 AM
Miroslav Grepl
 
Default Logrotate frustration - Selinux & Fail2Ban

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





--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:11 PM
Arthur Dent
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0

# semanage fcontext -l | grep fail2ban
/etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
/usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
/usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
/var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
/var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
/var/run/fail2ban.* all files system_ubject_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

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:17 PM
Arthur Dent
 
Default Logrotate frustration - Selinux & Fail2Ban

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

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:17 PM
Dominick Grift
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0
>
> # semanage fcontext -l | grep fail2ban
> /etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
> /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> /var/run/fail2ban.* all files system_ubject_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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:32 PM
Dominick Grift
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0
>
> # semanage fcontext -l | grep fail2ban
> /etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
> /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> /var/run/fail2ban.* all files system_ubject_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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:34 PM
Arthur Dent
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> > > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > > /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0
> >
> > # semanage fcontext -l | grep fail2ban
> > /etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
> > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > /var/run/fail2ban.* all files system_ubject_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_ubject_r:fail2ban_exec_t:s0

Is that what you would expect to see?

Thanks for your help - much appreciated...

Mark

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:36 PM
Dominick Grift
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> > > > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > > > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > > > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > > > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > > > /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0
> > >
> > > # semanage fcontext -l | grep fail2ban
> > > /etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
> > > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > > /var/run/fail2ban.* all files system_ubject_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_ubject_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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 12-07-2009, 09:44 PM
Arthur Dent
 
Default Logrotate frustration - Selinux & Fail2Ban

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_ubject_r:fail2ban_initrc_exec_t:s0
> > > > > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > > > > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > > > > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > > > > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > > > > /var/run/fail2ban.* all files system_ubject_r:fail2ban_var_run_t:s0
> > > >
> > > > # semanage fcontext -l | grep fail2ban
> > > > /etc/rc.d/init.d/fail2ban regular file system_ubject_r:fail2ban_initrc_exec_t:s0
> > > > /usr/bin/fail2ban regular file system_ubject_r:fail2ban_exec_t:s0
> > > > /usr/bin/fail2ban-server regular file system_ubject_r:fail2ban_exec_t:s0
> > > > /var/lib/fail2ban(/.*)? all files system_ubject_r:fail2ban_var_lib_t:s0
> > > > /var/log/fail2ban.log regular file system_ubject_r:fail2ban_log_t:s0
> > > > /var/run/fail2ban.* all files system_ubject_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_ubject_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_ubject_r:bin_t:s0 /usr/bin/fail2ban-server

Hmmmm...

# restorecon -v /usr/bin/fail2ban-server
restorecon reset /usr/bin/fail2ban-server context unconfined_ubject_r:bin_t:s0->system_ubject_r:fail2ban_exec_t:s0

# ls -alZ /usr/bin/fail2ban-server
-rwxr-xr-x. root root system_ubject_r:fail2ban_exec_t:s0 /usr/bin/fail2ban-server

Ahhh...

Is that more like it?

Thanks again!



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

Thread Tools




All times are GMT. The time now is 10:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org