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 04-09-2010, 09:05 AM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Fri, Apr 09, 2010 at 08:13:41AM +0100, Arthur Dent wrote:
> Hi Dominick,
>
> Still not quite there yet...
>
> (Apologies if there are duplicates here):
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762877.688:48174): avc: denied { signal } for pid=14587 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process
> node=troodos.org.uk type=SYSCALL msg=audit(1270762877.688:48174): arch=40000003 syscall=37 success=yes exit=0 a0=ffffc705 a1=f a2=2b9ff4 a3=1 items=0 ppid=1 pid=14587 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762931.148:48179): avc: denied { getattr } for pid=15736 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270762931.148:48179): arch=40000003 syscall=195 success=yes exit=0 a0=8c43fe a1=b64133dc a2=d1eff4 a3=3 items=0 ppid=15707 pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5 success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { read } for pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270762931.150:48180): avc: denied { open } for pid=15736 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270762931.150:48180): arch=40000003 syscall=5 success=yes exit=8 a0=8c43fe a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5 success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { read } for pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270762931.153:48181): avc: denied { open } for pid=15736 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270762931.153:48181): arch=40000003 syscall=5 success=yes exit=8 a0=8c4437 a1=0 a2=1b6 a3=8d15aa items=0 ppid=15707 pid=15736 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763183.873:48186): avc: denied { signal } for pid=15707 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process
> node=troodos.org.uk type=SYSCALL msg=audit(1270763183.873:48186): arch=40000003 syscall=37 success=yes exit=0 a0=ffffc2a5 a1=f a2=7ddff4 a3=1 items=0 ppid=1 pid=15707 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763457.339:48197): avc: denied { signal } for pid=15806 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=process
> node=troodos.org.uk type=SYSCALL msg=audit(1270763457.339:48197): arch=40000003 syscall=37 success=yes exit=0 a0=ffffc242 a1=f a2=5bdff4 a3=1 items=0 ppid=1 pid=15806 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763495.89:48202): avc: denied { getattr } for pid=15903 comm="mlogc" path="/etc/passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270763495.89:48202): arch=40000003 syscall=195 success=yes exit=0 a0=aee3fe a1=b63bb3dc a2=27bff4 a3=3 items=0 ppid=15881 pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5 success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { read } for pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270763495.104:48203): avc: denied { open } for pid=15903 comm="mlogc" name="passwd" dev=sda5 ino=1233517 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270763495.104:48203): arch=40000003 syscall=5 success=yes exit=8 a0=aee3fe a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5 success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { read } for pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270763495.107:48204): avc: denied { open } for pid=15903 comm="mlogc" name="tmp" dev=sda5 ino=820801 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:tmp_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270763495.107:48204): arch=40000003 syscall=5 success=yes exit=8 a0=aee437 a1=0 a2=1b6 a3=afb5aa items=0 ppid=15881 pid=15903 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270780538.4:48826): avc: denied { signal } for pid=24426 comm="httpd" scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tclass=process
> node=troodos.org.uk type=SYSCALL msg=audit(1270780538.4:48826): arch=40000003 syscall=37 success=yes exit=0 a0=5f6c a1=f a2=3851e4 a3=13ea018 items=0 ppid=24425 pid=24426 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3072 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0-s0:c0.c1023 key=(null)
>
> # cat avcs | audit2allow -R
>
> require {
> type httpd_t;
> type mlogc_t;
> class process signal;
> }
>
> #============= httpd_t ==============
> allow httpd_t mlogc_trocess signal;

This should have been allowed when we created mlogc_signal() in mlogc.if, and called mlogc_signal(httpd_t) in myapache.te as i suggested in my previous message.

Make sure that after you 've added this policy, that you rebuild and reinstall both myapache and mlogc modules:

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

>
> #============= mlogc_t ==============
> files_list_tmp(mlogc_t)

Above can be added.

> files_rw_etc_files(mlogc_t)

This is a bug in audit2allow -R: mlogc_t want to read /etc/passwd.
Add the following to your mlogc.te to allow it:

files_read_etc_files(mlogc_t)

>
>



> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-09-2010, 02:23 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

Hi Dominick,

I'm sorry to bother you again, but everything seems to be going just
fine since the last lot of policy updates, so I decided to move into the
next phase of my project.

You're going to hate me for this...

What I have is a Mod-Sec rule that detects a particular kind of attack;
when detected it identifies the IP address of the attacker and (using
the modsec "exec" function) passes this to a script.

During our recent exchange I was using this rule for testing, but for
now all the script does is write the IP address into a file. (This
worked by the way).

Now for the next part. Instead of writing it to a file I want to ban the
IP in iptables using a feature of the fail2ban application which I also
have running on this machine.

The script uses the following command:
fail2ban-client set modsec banip $IP
touch -c /var/log/httpd/modsec_audit.log

where $IP is the IP address passes from mod-sec, the "banip" is a
argument of the fail2ban-client app which initiates a manual banning of
the IP and "modsec" is the name of the "jail" (in fail2ban parlance) to
be activated for this IP.

The "touch" command is necessary to trick fail2ban into thinking that
the log file it is monitoring has been updated and thus needs to wake
itself and take action.

Putting all this together now gives me this (single) avc when testing:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_ubject_r:fail2ban_var_run_t:s0 tclass=dir
node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222 pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

How best to handle this?

I am writing this from behind the sofa, out of range of beer bottles
hurled from the Netherlands.

Thanks!

Mark




--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-09-2010, 03:10 PM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
> Hi Dominick,
>
> I'm sorry to bother you again, but everything seems to be going just
> fine since the last lot of policy updates, so I decided to move into the
> next phase of my project.
>
> You're going to hate me for this...
>
> What I have is a Mod-Sec rule that detects a particular kind of attack;
> when detected it identifies the IP address of the attacker and (using
> the modsec "exec" function) passes this to a script.
>
> During our recent exchange I was using this rule for testing, but for
> now all the script does is write the IP address into a file. (This
> worked by the way).
>
> Now for the next part. Instead of writing it to a file I want to ban the
> IP in iptables using a feature of the fail2ban application which I also
> have running on this machine.
>
> The script uses the following command:
> fail2ban-client set modsec banip $IP
> touch -c /var/log/httpd/modsec_audit.log
>
> where $IP is the IP address passes from mod-sec, the "banip" is a
> argument of the fail2ban-client app which initiates a manual banning of
> the IP and "modsec" is the name of the "jail" (in fail2ban parlance) to
> be activated for this IP.
>
> The "touch" command is necessary to trick fail2ban into thinking that
> the log file it is monitoring has been updated and thus needs to wake
> itself and take action.
>
> Putting all this together now gives me this (single) avc when testing:
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_ubject_r:fail2ban_var_run_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222 pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>
> How best to handle this?

I am not sure if i understand how that goes. From the avc denials above i can tell that fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but some process in the httpd_t domain.

What runs the script?


>
> I am writing this from behind the sofa, out of range of beer bottles
> hurled from the Netherlands.
>
> Thanks!
>
> Mark
>
>
>
>



> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-09-2010, 03:26 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
> On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
> > Hi Dominick,
> >
> > I'm sorry to bother you again, but everything seems to be going just
> > fine since the last lot of policy updates, so I decided to move into the
> > next phase of my project.
> >
> > You're going to hate me for this...
> >
> > What I have is a Mod-Sec rule that detects a particular kind of attack;
> > when detected it identifies the IP address of the attacker and (using
> > the modsec "exec" function) passes this to a script.
> >
> > During our recent exchange I was using this rule for testing, but for
> > now all the script does is write the IP address into a file. (This
> > worked by the way).
> >
> > Now for the next part. Instead of writing it to a file I want to ban the
> > IP in iptables using a feature of the fail2ban application which I also
> > have running on this machine.
> >
> > The script uses the following command:
> > fail2ban-client set modsec banip $IP
> > touch -c /var/log/httpd/modsec_audit.log
> >
> > where $IP is the IP address passes from mod-sec, the "banip" is a
> > argument of the fail2ban-client app which initiates a manual banning of
> > the IP and "modsec" is the name of the "jail" (in fail2ban parlance) to
> > be activated for this IP.
> >
> > The "touch" command is necessary to trick fail2ban into thinking that
> > the log file it is monitoring has been updated and thus needs to wake
> > itself and take action.
> >
> > Putting all this together now gives me this (single) avc when testing:
> >
> > Raw Audit Messages :
> >
> > node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_ubject_r:fail2ban_var_run_t:s0 tclass=dir
> > node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222 pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
> >
> > How best to handle this?
>
> I am not sure if i understand how that goes. From the avc denials above i can tell that fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but some process in the httpd_t domain.
>
> What runs the script?

I guess it must be mod-security itself.

I have a rule in modsec as follows:

SecRule REQUEST_URI_RAW "(?:wantsfly|w00tw00t)" "phase:1,t:lowercase,deny,log,status:403, setenv:REMOTEIP=%{REMOTE_ADDR}, exec:/usr/local/bin/banip2.sh"

This means that if someone tries to probe my webserver with a typical
signature (in this case "wantsfly") Mod-Security will execute the
script /usr/local/bin/banip2.sh within which "fail2ban-client" is called
to block the IP address in iptables.

Does that make sense?

Thanks

Mark



--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-09-2010, 03:44 PM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Fri, Apr 09, 2010 at 04:26:05PM +0100, Arthur Dent wrote:
> On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
> > On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
> > > Hi Dominick,
> > >
> > > I'm sorry to bother you again, but everything seems to be going just
> > > fine since the last lot of policy updates, so I decided to move into the
> > > next phase of my project.
> > >
> > > You're going to hate me for this...
> > >
> > > What I have is a Mod-Sec rule that detects a particular kind of attack;
> > > when detected it identifies the IP address of the attacker and (using
> > > the modsec "exec" function) passes this to a script.
> > >
> > > During our recent exchange I was using this rule for testing, but for
> > > now all the script does is write the IP address into a file. (This
> > > worked by the way).
> > >
> > > Now for the next part. Instead of writing it to a file I want to ban the
> > > IP in iptables using a feature of the fail2ban application which I also
> > > have running on this machine.
> > >
> > > The script uses the following command:
> > > fail2ban-client set modsec banip $IP
> > > touch -c /var/log/httpd/modsec_audit.log
> > >
> > > where $IP is the IP address passes from mod-sec, the "banip" is a
> > > argument of the fail2ban-client app which initiates a manual banning of
> > > the IP and "modsec" is the name of the "jail" (in fail2ban parlance) to
> > > be activated for this IP.
> > >
> > > The "touch" command is necessary to trick fail2ban into thinking that
> > > the log file it is monitoring has been updated and thus needs to wake
> > > itself and take action.
> > >
> > > Putting all this together now gives me this (single) avc when testing:
> > >
> > > Raw Audit Messages :
> > >
> > > node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied { search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5 ino=476186 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_ubject_r:fail2ban_var_run_t:s0 tclass=dir
> > > node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222 pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
> > >
> > > How best to handle this?
> >
> > I am not sure if i understand how that goes. From the avc denials above i can tell that fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but some process in the httpd_t domain.
> >
> > What runs the script?
>
> I guess it must be mod-security itself.
>
> I have a rule in modsec as follows:
>
> SecRule REQUEST_URI_RAW "(?:wantsfly|w00tw00t)" "phase:1,t:lowercase,deny,log,status:403, setenv:REMOTEIP=%{REMOTE_ADDR}, exec:/usr/local/bin/banip2.sh"
>
> This means that if someone tries to probe my webserver with a typical
> signature (in this case "wantsfly") Mod-Security will execute the
> script /usr/local/bin/banip2.sh within which "fail2ban-client" is called
> to block the IP address in iptables.
>
> Does that make sense?
Yes. I guess i would confine /usr/local/bin/banip2.sh and set up a transition from httpd_t to a new banip2_t domain

Basically pretty much similar to what we did with mlogc

It would be a good exercise if you would try that. Basically follow the steps described in previous messages.
only this time you do not have to create a new myapache module you can just extend the existing with interface calls to your new banip2 module.

>
> Thanks
>
> Mark
>
>
>



> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-12-2010, 08:50 AM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Fri, 2010-04-09 at 17:44 +0200, Dominick Grift wrote:
> On Fri, Apr 09, 2010 at 04:26:05PM +0100, Arthur Dent wrote:
> > On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
> > > On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
> > > > Hi Dominick,
> > > >

[snip]

> > Does that make sense?
> Yes. I guess i would confine /usr/local/bin/banip2.sh and set up a transition from httpd_t to a new banip2_t domain
>
> Basically pretty much similar to what we did with mlogc
>
> It would be a good exercise if you would try that. Basically follow the steps described in previous messages.
> only this time you do not have to create a new myapache module you can just extend the existing with interface calls to your new banip2 module.

I just thought I would give a quick update on this...

I was quite up for the challenge of writing my own policy for this, but
realised that I had to get the script working properly first. Although
the script worked fine when executed from the command line, it did not
when run in the normal environment. I realised that the fail2ban-client
app called from within the script needs to run as root. After much
messing around, trying (and failing) with sudo and su- commands, editing
sudoers and much other wasted effort I was stuck. Then, in a rare (for
me) moment of clear-thinking I realised that the way fail2ban works, and
is designed to work, is by monitoring log files for new entries and then
banning the IP if the entry matches a regex. So all I had to do was to
get the script to write the IP into a "log file" (which it already was)
together with a timestamp, and set fail2ban to monitor that log file...

Simple!

And not an AVC in sight!

So thanks for all your help.

I think I am now ready to remove the "permissive mlogc_t;" directive
from mlogc.te and put the system back into Enforcing mode.

Cheers!

Mark


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-25-2010, 06:20 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

Hello Dominick,

I don't know if you remember all the painful details of the thread where
you helped me solve my mlogc problems but, after running for a couple of
weeks in enforcing mode I occasionally get these AVCs when my
ModSecurity rule triggers a block which is reported in mlogc:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271810736.442:85299): avc: denied { read } for pid=30941 comm="mlogc" name="stat" dev=proc ino=4026531985 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1271810736.442:85299): arch=40000003 syscall=5 success=no exit=-13 a0=ceeb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)


Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271810736.446:85300): avc: denied { read } for pid=30941 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1271810736.446:85300): arch=40000003 syscall=5 success=no exit=-13 a0=ceeb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1272206914.57:99302): avc: denied { read } for pid=2650 comm="mlogc" name="stat" dev=proc ino=4026531985 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1272206914.57:99302): arch=40000003 syscall=5 success=no exit=-13 a0=24bb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1272206914.61:99303): avc: denied { read } for pid=2650 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1272206914.61:99303): arch=40000003 syscall=5 success=no exit=-13 a0=24bb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)


Audit2allow suggests:

require {
type mlogc_t;
type proc_t;
class file read;
}

#============= mlogc_t ==============
allow mlogc_t proc_t:file read;

But when I try to add that to my mlogc.te it chokes during the build
process...

I should point out that, as far as I can tell, everything still works
despite the AVC denial...

Thanks yet again for your patient help!

Mark

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 04-25-2010, 06:35 PM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Sun, Apr 25, 2010 at 07:20:12PM +0100, Arthur Dent wrote:
> Hello Dominick,
>
> I don't know if you remember all the painful details of the thread where
> you helped me solve my mlogc problems but, after running for a couple of
> weeks in enforcing mode I occasionally get these AVCs when my
> ModSecurity rule triggers a block which is reported in mlogc:
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1271810736.442:85299): avc: denied { read } for pid=30941 comm="mlogc" name="stat" dev=proc ino=4026531985 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1271810736.442:85299): arch=40000003 syscall=5 success=no exit=-13 a0=ceeb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1271810736.446:85300): avc: denied { read } for pid=30941 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1271810736.446:85300): arch=40000003 syscall=5 success=no exit=-13 a0=ceeb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=30941 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1272206914.57:99302): avc: denied { read } for pid=2650 comm="mlogc" name="stat" dev=proc ino=4026531985 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1272206914.57:99302): arch=40000003 syscall=5 success=no exit=-13 a0=24bb6e a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1272206914.61:99303): avc: denied { read } for pid=2650 comm="mlogc" name="cpuinfo" dev=proc ino=4026531980 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rroc_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1272206914.61:99303): arch=40000003 syscall=5 success=no exit=-13 a0=24bb79 a1=80000 a2=0 a3=2000 items=0 ppid=32219 pid=2650 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:mlogc_t:s0 key=(null)
>
>
> Audit2allow suggests:
>
> require {
> type mlogc_t;
> type proc_t;
> class file read;
> }
>
> #============= mlogc_t ==============
> allow mlogc_t proc_t:file read;
>
> But when I try to add that to my mlogc.te it chokes during the build
> process...

Chokes? what exactly gets printed to the screen?

try adding "kernel_read_system_state(mlogc_t) to your mlogc.te file and rebuild, reinstall.

>
> I should point out that, as far as I can tell, everything still works
> despite the AVC denial...
>
> Thanks yet again for your patient help!
>
> Mark
>



> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 02:35 AM.

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