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-07-2010, 10:20 PM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Wed, Apr 07, 2010 at 11:01:53PM +0100, Arthur Dent wrote:
> On Wed, 2010-04-07 at 23:35 +0200, Dominick Grift wrote:
>
> >
> > Yes looks fine. try the following myapache.te instead:
> >
> > policy_module(myapache, 1.0.0)
> > gen_require(`
> > type httpd_t;
> > ')
> > mlogc_domtrans(httpd_t)
> >
> > build, install
> >
> > make -f /usr/share/selinux/devel/Makefile
> > sudo semodule -i *.pp
>
> OK - Caused a mere 16 AVCs (admittedly in permissive mode):

Alright we are on the right track now. the mlogc process runs in its own mlogc domain.
Now to add some more policy to mlogc.te

see comments below:

>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { write } for pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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(1270677188.477:44957): avc: denied { write } for pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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(1270677188.477:44957): avc: denied { write } for pid=952 comm="mlogc" name="mlogc" dev=sda5 ino=578025 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { add_name } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=AVC msg=audit(1270677188.477:44957): avc: denied { create } for pid=952 comm="mlogc" name="mlogc-queue.log.new" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.477:44957): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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(1270677188.484:44958): avc: denied { remove_name } for pid=952 comm="mlogc" name="mlogc-queue.log" dev=sda5 ino=578431 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.484:44958): arch=40000003 syscall=38 success=yes exit=0 a0=84c01e8 a1=b76fd070 a2=7581e4 a3=0 items=0 ppid=937 pid=952 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(1270677188.494:44959): avc: denied { rename } for pid=952 comm="mlogc" name="mlogc-queue.log.new" dev=sda5 ino=578432 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.494:44959): arch=40000003 syscall=38 success=yes exit=0 a0=b76fd170 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937 pid=952 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)

The above access vectors should all be allowed if you add the following to your mlogc.te file:

apache_manage_log(mlogc_t)

>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270677188.497:44960): avc: denied { write } for pid=952 comm="mlogc" name="mlogc-transaction.log" dev=sda5 ino=578031 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:httpd_sys_content_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677188.497:44960): arch=40000003 syscall=194 success=yes exit=0 a0=5 a1=0 a2=0 a3=84c05c0 items=0 ppid=937 pid=952 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)
>

The file mlogc-transaction.log at inode 57803 seems mislabeled. use restorecon on the file to fix its context.

>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270677208.496:44961): avc: denied { unlink } for pid=952 comm="mlogc" name="mlogc-queue.log.old" dev=sda5 ino=578432 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677208.496:44961): arch=40000003 syscall=10 success=yes exit=0 a0=b76fd070 a1=84c01e8 a2=7581e4 a3=0 items=0 ppid=937 pid=952 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(1270677254.661:44966): avc: denied { create } for pid=944 comm="httpd" name="20100407-2254" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.661:44966): arch=40000003 syscall=39 success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937 pid=944 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 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(1270677254.673:44967): avc: denied { write } for pid=944 comm="httpd" name="20100407-225414-S7z-BlIrkOUAAAOwOYMAAAAB" dev=sda5 ino=658630 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.673:44967): arch=40000003 syscall=5 success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=944 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>

The access vectors above were allowed when we added apache_manage_log(mlogc_t) to our mlogc.te file.

>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270677254.679:44968): avc: denied { setopt } for pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=tcp_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.679:44968): arch=40000003 syscall=102 success=yes exit=0 a0=e a1=b62fa5d0 a2=3ff8550 a3=b62fa640 items=0 ppid=937 pid=1412 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(1270677254.682:44969): avc: denied { write } for pid=1412 comm="mlogc" laddr=127.0.0.1 lport=56280 faddr=127.0.0.1 fport=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=tcp_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.682:44969): arch=40000003 syscall=102 success=yes exit=37 a0=9 a1=b62fa560 a2=3ff8550 a3=0 items=0 ppid=937 pid=1412 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)
>

The above can be allowed by adding the following to you mlogc.te file:

allow mlogc_t self:tcp_socket create_socket_perms;

> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270677254.684:44970): avc: denied { create } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=udp_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.684:44970): arch=40000003 syscall=102 success=yes exit=7 a0=1 a1=b62fa5c0 a2=4cb9a8 a3=b577c630 items=0 ppid=937 pid=1412 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)
>


The above can be allowed by adding the following to your mlogc.te file:

allow mlogc_t self:udp_socket create_socket_perms;

> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(127067725d4.685:44971): avc: denied { create } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44971): arch=40000003 syscall=102 success=yes exit=7 a0=1 a1=b62fa400 a2=d1eff4 a3=b62fa5e8 items=0 ppid=937 pid=1412 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(1270677254.685:44972): avc: denied { bind } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.685:44972): arch=40000003 syscall=102 success=yes exit=0 a0=2 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412 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(1270677254.686:44973): avc: denied { getattr } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44973): arch=40000003 syscall=102 success=yes exit=0 a0=6 a1=b62fa400 a2=d1eff4 a3=7 items=0 ppid=937 pid=1412 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(1270677254.686:44974): avc: denied { write } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket
> node=troodos.org.uk type=AVC msg=audit(1270677254.686:44974): avc: denied { nlmsg_read } for pid=1412 comm="mlogc" scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=netlink_route_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270677254.686:44974): arch=40000003 syscall=102 success=yes exit=20 a0=b a1=b62f9330 a2=d1eff4 a3=0 items=0 ppid=937 pid=1412 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)
>

The above can be allowed by adding the following to your mlogc.te file:

allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;


I did this quickly off the top of my head, so might be some syntax errors.

It is getting late and i am tired. I will respond to any emails tomorrow morning.

we are on the right track.

> --
> 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-07-2010, 10:42 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Thu, 2010-04-08 at 00:20 +0200, Dominick Grift wrote:

> Alright we are on the right track now. the mlogc process runs in its own mlogc domain.
> Now to add some more policy to mlogc.te
>
> see comments below:

[snip]

> I did this quickly off the top of my head, so might be some syntax errors.
>
> It is getting late and i am tired. I will respond to any emails tomorrow morning.

It's 11:30pm here... I really appreciate your help - Thanks!

> we are on the right track.

Yes.

A half-dozen AVCs sinc that last update to policy:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270679719.656:45083): avc: denied { create } for pid=949 comm="httpd" name="20100407-2335" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=dir
node=troodos.org.uk type=SYSCALL msg=audit(1270679719.656:45083): arch=40000003 syscall=39 success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937 pid=949 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 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(1270679719.705:45084): avc: denied { write } for pid=949 comm="httpd" name="20100407-233519-S70IpVIrkOUAAAO1OuQAAAAF" dev=sda5 ino=658634 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270679719.705:45084): arch=40000003 syscall=5 success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=949 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 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(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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(1270679720.298:45086): avc: denied { getattr } for pid=1869 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.298:45086): arch=40000003 syscall=195 success=yes exit=0 a0=1c85ab a1=b62f89ac a2=d1eff4 a3=3 items=0 ppid=937 pid=1869 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(1270679720.301:45087): avc: denied { read } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5 success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869 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(1270679720.301:45087): avc: denied { read } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5 success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869 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)


And as I was copying the above, this one came in...

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)


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

On Wed, Apr 07, 2010 at 11:42:47PM +0100, Arthur Dent wrote:
> On Thu, 2010-04-08 at 00:20 +0200, Dominick Grift wrote:
>
> > Alright we are on the right track now. the mlogc process runs in its own mlogc domain.
> > Now to add some more policy to mlogc.te
> >
> > see comments below:
>
> [snip]
>
> > I did this quickly off the top of my head, so might be some syntax errors.
> >
> > It is getting late and i am tired. I will respond to any emails tomorrow morning.
>
> It's 11:30pm here... I really appreciate your help - Thanks!
>
> > we are on the right track.
>
> Yes.

Comments below:

>
> A half-dozen AVCs sinc that last update to policy:
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270679719.656:45083): avc: denied { create } for pid=949 comm="httpd" name="20100407-2335" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=dir
> node=troodos.org.uk type=SYSCALL msg=audit(1270679719.656:45083): arch=40000003 syscall=39 success=yes exit=0 a0=24e17a8 a1=1e8 a2=80a1e4 a3=24e1748 items=0 ppid=937 pid=949 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 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(1270679719.705:45084): avc: denied { write } for pid=949 comm="httpd" name="20100407-233519-S70IpVIrkOUAAAO1OuQAAAAF" dev=sda5 ino=658634 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_ubject_r:httpd_log_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270679719.705:45084): arch=40000003 syscall=5 success=yes exit=19 a0=24e1748 a1=8241 a2=1a0 a3=836 items=0 ppid=937 pid=949 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
>

I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.

This brings us to a security issue need to consider and deal with.

As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.

Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.

So how can we deal with this? Well there are something we should investigate.

Can we configure mod_security to use a custom location for its log files?
Maybe we do not have to:

Can you tell me which directories in /var/log/httpd are owned by mod_security?

I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
This will benefit security as:

1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.

We must try to find the best solution to the above securities issue so again: two questions:

1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?


> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)

The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.

1. Why is it connecting to the network?
2. What is listening on tcp:8888 on the other side?

We have to find some answers before we can start implementing a proper solution.

>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270679720.298:45086): avc: denied { getattr } for pid=1869 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270679720.298:45086): arch=40000003 syscall=195 success=yes exit=0 a0=1c85ab a1=b62f89ac a2=d1eff4 a3=3 items=0 ppid=937 pid=1869 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(1270679720.301:45087): avc: denied { read } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5 success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869 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(1270679720.301:45087): avc: denied { read } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
> node=troodos.org.uk type=AVC msg=audit(1270679720.301:45087): avc: denied { open } for pid=1869 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rcscd_var_run_t:s0 tclass=file
> node=troodos.org.uk type=SYSCALL msg=audit(1270679720.301:45087): arch=40000003 syscall=5 success=yes exit=13 a0=1c88ea a1=0 a2=1b6 a3=1c88e8 items=0 ppid=937 pid=1869 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)

The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.

Add the following to your mlogc.te file:

pcscd_read_pub_files(mlogc_t)

That should allow mlogc_t to read pcscd pid files.

>
>
> And as I was copying the above, this one came in...
>
> Raw Audit Messages :
>
> node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
>
>

The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.


Now we are getting into the harder aspect of writing policy.
Writing a template for a new domain and just allowing access is not so hard.
What is harder is: making solid security decisions.


What is it doing
why is it doing it
who is doing it to who
Is this a threat
why is it a threat
how can we neutralize it?

fun!

> --
> 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-08-2010, 08:40 AM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:

[snip]
>
> I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.
>
> This brings us to a security issue need to consider and deal with.
>
> As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.
>
> Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.
>
> So how can we deal with this? Well there are something we should investigate.
>
> Can we configure mod_security to use a custom location for its log files?
> Maybe we do not have to:
>
> Can you tell me which directories in /var/log/httpd are owned by mod_security?

OK - Here is the story:

I have been using mod-security for some time now with none of theses
shenanigans...

Normally mod-security writes its logs to /var/log/httpd/ (the same place
as the apache logs) and there are only 2 files:
/var/log/httpd/modsec_audit.log
/var/log/httpd/modsec_debug.log

The audit log being the main workhorse where each individual mod-sec
action was recorded.

All of that was fine. mlogc was not involved.

Recently, I decided to start using the Mod-Security Community Console, a
(java-based I think) web app for viewing, and giving more user-friendly
detail of, all the alerts produced by mod-sec.

This requires a different approach to logging and this is where mlogc
comes in.

Mod-security has two logging modes, serial and concurrent. "Serial"
places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
on the other hand, places log files in separate directories
corresponding to the time that the log was generated. This is what is
required by the Console app.

This is configured from
the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
the following directives:

For Concurrent logging:-
SecAuditLogType Concurrent #(sets logging type)
SecDataDir /var/log/httpd/modsec_data # Sets log location
SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc

For Serial Logging:-
#SecAuditLogType Serial
#SecAuditLog logs/modsec_audit.log

Mlogc has its own configuration:
/etc/mlogc.conf

I reproduce it in full here:


# cat /etc/mlogc.conf
################################################## ########################
# Required configuration
# At a minimum, the items in this section will need to be adjusted to
# fit your environment. The remaining options are optional.
################################################## ########################

# Points to the root of the installation. All relative
# paths will be resolved with the help of this path.
CollectorRoot "/var/log/httpd/mlogc"

# ModSecurity Console receiving URI. You can change the host
# and the port parts but leave everything else as is.
ConsoleURI "https://127.0.0.1:8888/rpc/auditLogReceiver"

# Sensor credentials
SensorUsername "MCS"
SensorPassword "mypassword"

# Base directory where the audit logs are stored. This can be specified
# as a path relative to the CollectorRoot, or a full path.
LogStorageDir "data"

# Transaction log will contain the information on all log collector
# activities that happen between checkpoints. The transaction log
# is used to recover data in case of a crash (or if Apache kills
# the process).
TransactionLog "mlogc-transaction.log"

# The file where the pending audit log entry data is kept. This file
# is updated on every checkpoint.
QueuePath "mlogc-queue.log"

# The location of the error log.
ErrorLog "mlogc-error.log"

# The location of the lock file.
LockFile "mlogc.lck"

# Keep audit log entries after sending? (0=false 1=true)
# NOTE: This is required to be set in SecAuditLog mlogc config if you
# are going to use a secondary console via SecAuditLog2.
KeepEntries 0


################################################## ########################
# Optional configuration
################################################## ########################

# The error log level controls how much detail there
# will be in the error log. The levels are as follows:
# 0 - NONE
# 1 - ERROR
# 2 - WARNING
# 3 - NOTICE
# 4 - DEBUG
# 5 - DEBUG2
#
ErrorLogLevel 3

# How many concurrent connections to the server
# are we allowed to open at the same time? Log collector uses
# multiple connections in order to speed up audit log transfer.
# This is especially needed when the communication takes place
# over a slow link (e.g. not over a LAN).
MaxConnections 10

# How many requests a worker will process before recycling itself.
# This is to help prevent problems due to any memory leaks that may
# exists. If this is set to 0, then no maximum is imposed. The default
# is 1000 requests per worker (the number of workers is controlled by
the
# MaxConnections limit).
MaxWorkerRequests 1000

# The time each connection will sit idle before being reused,
# in milliseconds. Increase if you don't want ModSecurity Console
# to be hit with too many log collector requests.
TransactionDelay 50

# The time to wait before initialization on startup in milliseconds.
# Increase if mlogc is starting faster then termination when the
# sensor is reloaded.
StartupDelay 5000

# How often is the pending audit log entry data going to be written
# to a file. The default is 15 seconds.
CheckpointInterval 15

# If the server fails all threads will back down until the
# problem is sorted. The management thread will periodically
# launch a thread to test the server. The default is to test
# once in 60 seconds.
ServerErrorTimeout 60

# The following two parameters are not used yet, but
# reserved for future expansion.
# KeepAlive 150
# KeepAliveTimeout 300

################################################## ###############################

I think most of that is self-explanatory. Note especially the ConsoleURI
"https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
alerts into the Console which listens on port 8888, and this is the
answer to one of your later questions.

Note however that I am also experimenting with another Console app (also
Java based, which does exactly the same thing in the same way) but in
this case listens on port 8443.

>
> I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> This will benefit security as:
>
> 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
>
> We must try to find the best solution to the above securities issue so again: two questions:
>
> 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?

The answer to 1 is yes as you can see above.
>
> > Raw Audit Messages :
> >
> > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
>
> The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
>
> 1. Why is it connecting to the network?
> 2. What is listening on tcp:8888 on the other side?

That's the Console app as described above.

>
> We have to find some answers before we can start implementing a proper solution.

[snip]

> The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
>
> Add the following to your mlogc.te file:
>
> pcscd_read_pub_files(mlogc_t)
>
> That should allow mlogc_t to read pcscd pid files.

Done that - thanks..

>
> >
> >
> > And as I was copying the above, this one came in...
> >
> > Raw Audit Messages :
> >
> > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> >
> >
>
> The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
>
>
> Now we are getting into the harder aspect of writing policy.
> Writing a template for a new domain and just allowing access is not so hard.
> What is harder is: making solid security decisions.
>
>
> What is it doing
> why is it doing it
> who is doing it to who
> Is this a threat
> why is it a threat
> how can we neutralize it?
>
> fun!

For you maybe

OK - I hope the above helps...

By the way since my last message I have had another 71 AVcs - too many
to post, and doubtless many duplicates, but here is what audit2allow has
to say about them:

# ausearch -m AVC -ts today | audit2allow -R

require {
type mlogc_t;
type httpd_t;
class capability { sys_nice dac_override };
class process { setsched signal getsched };
class sem { read write create unix_write destroy };
}

#============= httpd_t ==============
allow httpd_t mlogc_trocess signal;

#============= mlogc_t ==============
allow mlogc_t self:capability { sys_nice dac_override };
allow mlogc_t selfrocess { setsched getsched };
allow mlogc_t self:sem { read write create unix_write destroy };
files_rw_etc_files(mlogc_t)
miscfiles_rw_localization(mlogc_t)



Thanks again for all your help!

Cheers

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

On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
> On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
>
> [snip]
> >
> > I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.
> >
> > This brings us to a security issue need to consider and deal with.
> >
> > As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.
> >
> > Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.
> >
> > So how can we deal with this? Well there are something we should investigate.
> >
> > Can we configure mod_security to use a custom location for its log files?
> > Maybe we do not have to:
> >
> > Can you tell me which directories in /var/log/httpd are owned by mod_security?
>
> OK - Here is the story:
>
> I have been using mod-security for some time now with none of theses
> shenanigans...
>
> Normally mod-security writes its logs to /var/log/httpd/ (the same place
> as the apache logs) and there are only 2 files:
> /var/log/httpd/modsec_audit.log
> /var/log/httpd/modsec_debug.log
>
> The audit log being the main workhorse where each individual mod-sec
> action was recorded.
>
> All of that was fine. mlogc was not involved.
>
> Recently, I decided to start using the Mod-Security Community Console, a
> (java-based I think) web app for viewing, and giving more user-friendly
> detail of, all the alerts produced by mod-sec.
>
> This requires a different approach to logging and this is where mlogc
> comes in.
>
> Mod-security has two logging modes, serial and concurrent. "Serial"
> places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
> on the other hand, places log files in separate directories
> corresponding to the time that the log was generated. This is what is
> required by the Console app.
>
> This is configured from
> the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
> the following directives:
>
> For Concurrent logging:-
> SecAuditLogType Concurrent #(sets logging type)
> SecDataDir /var/log/httpd/modsec_data # Sets log location
> SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
> SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
>
> For Serial Logging:-
> #SecAuditLogType Serial
> #SecAuditLog logs/modsec_audit.log
>
> Mlogc has its own configuration:
> /etc/mlogc.conf
>
> I reproduce it in full here:
>
>
> # cat /etc/mlogc.conf
> ################################################## ########################
> # Required configuration
> # At a minimum, the items in this section will need to be adjusted to
> # fit your environment. The remaining options are optional.
> ################################################## ########################
>
> # Points to the root of the installation. All relative
> # paths will be resolved with the help of this path.
> CollectorRoot "/var/log/httpd/mlogc"
>
> # ModSecurity Console receiving URI. You can change the host
> # and the port parts but leave everything else as is.
> ConsoleURI "https://127.0.0.1:8888/rpc/auditLogReceiver"
>
> # Sensor credentials
> SensorUsername "MCS"
> SensorPassword "mypassword"
>
> # Base directory where the audit logs are stored. This can be specified
> # as a path relative to the CollectorRoot, or a full path.
> LogStorageDir "data"
>
> # Transaction log will contain the information on all log collector
> # activities that happen between checkpoints. The transaction log
> # is used to recover data in case of a crash (or if Apache kills
> # the process).
> TransactionLog "mlogc-transaction.log"
>
> # The file where the pending audit log entry data is kept. This file
> # is updated on every checkpoint.
> QueuePath "mlogc-queue.log"
>
> # The location of the error log.
> ErrorLog "mlogc-error.log"
>
> # The location of the lock file.
> LockFile "mlogc.lck"
>
> # Keep audit log entries after sending? (0=false 1=true)
> # NOTE: This is required to be set in SecAuditLog mlogc config if you
> # are going to use a secondary console via SecAuditLog2.
> KeepEntries 0
>
>
> ################################################## ########################
> # Optional configuration
> ################################################## ########################
>
> # The error log level controls how much detail there
> # will be in the error log. The levels are as follows:
> # 0 - NONE
> # 1 - ERROR
> # 2 - WARNING
> # 3 - NOTICE
> # 4 - DEBUG
> # 5 - DEBUG2
> #
> ErrorLogLevel 3
>
> # How many concurrent connections to the server
> # are we allowed to open at the same time? Log collector uses
> # multiple connections in order to speed up audit log transfer.
> # This is especially needed when the communication takes place
> # over a slow link (e.g. not over a LAN).
> MaxConnections 10
>
> # How many requests a worker will process before recycling itself.
> # This is to help prevent problems due to any memory leaks that may
> # exists. If this is set to 0, then no maximum is imposed. The default
> # is 1000 requests per worker (the number of workers is controlled by
> the
> # MaxConnections limit).
> MaxWorkerRequests 1000
>
> # The time each connection will sit idle before being reused,
> # in milliseconds. Increase if you don't want ModSecurity Console
> # to be hit with too many log collector requests.
> TransactionDelay 50
>
> # The time to wait before initialization on startup in milliseconds.
> # Increase if mlogc is starting faster then termination when the
> # sensor is reloaded.
> StartupDelay 5000
>
> # How often is the pending audit log entry data going to be written
> # to a file. The default is 15 seconds.
> CheckpointInterval 15
>
> # If the server fails all threads will back down until the
> # problem is sorted. The management thread will periodically
> # launch a thread to test the server. The default is to test
> # once in 60 seconds.
> ServerErrorTimeout 60
>
> # The following two parameters are not used yet, but
> # reserved for future expansion.
> # KeepAlive 150
> # KeepAliveTimeout 300
>
> ################################################## ###############################


Alright. I wonder why they put that location in httpd's log location. From a SELinux
perspective it would makes things a bit simpler if they just set:

SecAuditLogStorageDir /var/log/mlogc/data
CollectorRoot "/var/log/mlogc"
LogStorageDir "data"

Then we can easily create a new log file type for mlogc log content in /var/log and set up a file type transition:

mlogc.te:

# declare a type and make the type usable for mlogc log content
type mlogc_var_log_t;
logging_log_file(mlogc_var_log_t;

# allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })

Next we add a file context specification for this in mlogc.fc:

/var/log/mlogc(/.*)? gen_context(system_ubject_r:mlogc_var_log_t, s0)

We should for now comment out or remove the "apache_manage_log(mlogc_t)" in mlogc.te that we added earlier for the time being.

>
> I think most of that is self-explanatory. Note especially the ConsoleURI
> "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> alerts into the Console which listens on port 8888, and this is the
> answer to one of your later questions.

I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?

>
> Note however that I am also experimenting with another Console app (also
> Java based, which does exactly the same thing in the same way) but in
> this case listens on port 8443.
>
> >
> > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > This will benefit security as:
> >
> > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> >
> > We must try to find the best solution to the above securities issue so again: two questions:
> >
> > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
>
> The answer to 1 is yes as you can see above.
> >
> > > Raw Audit Messages :
> > >
> > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> >
> > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> >
> > 1. Why is it connecting to the network?
> > 2. What is listening on tcp:8888 on the other side?
>
> That's the Console app as described above.
>
> >
> > We have to find some answers before we can start implementing a proper solution.
>
> [snip]
>
> > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> >
> > Add the following to your mlogc.te file:
> >
> > pcscd_read_pub_files(mlogc_t)
> >
> > That should allow mlogc_t to read pcscd pid files.
>
> Done that - thanks..
>
> >
> > >
> > >
> > > And as I was copying the above, this one came in...
> > >
> > > Raw Audit Messages :
> > >
> > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > >
> > >
> >
> > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> >
> >
> > Now we are getting into the harder aspect of writing policy.
> > Writing a template for a new domain and just allowing access is not so hard.
> > What is harder is: making solid security decisions.
> >
> >
> > What is it doing
> > why is it doing it
> > who is doing it to who
> > Is this a threat
> > why is it a threat
> > how can we neutralize it?
> >
> > fun!
>
> For you maybe
>
> OK - I hope the above helps...
>
> By the way since my last message I have had another 71 AVcs - too many
> to post, and doubtless many duplicates, but here is what audit2allow has
> to say about them:
>
> # ausearch -m AVC -ts today | audit2allow -R
>
> require {
> type mlogc_t;
> type httpd_t;
> class capability { sys_nice dac_override };
> class process { setsched signal getsched };
> class sem { read write create unix_write destroy };
> }
>
> #============= httpd_t ==============
> allow httpd_t mlogc_trocess signal;

Ignore this for now, we might add it later.

>
> #============= mlogc_t ==============
> allow mlogc_t self:capability { sys_nice dac_override };

Did you figure out which location not owned by root mlogc is trying to access?
For the moment lets ignore these.

> allow mlogc_t selfrocess { setsched getsched };

The above can be added to mlogc.te

> allow mlogc_t self:sem { read write create unix_write destroy };

Ignore for now

> files_rw_etc_files(mlogc_t)

I suspect that mlogc_t is writing to its own configuration file but i cannot be sure until i see the avc denials
related to this:

ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write


> miscfiles_rw_localization(mlogc_t)

This is a misinterpretation by the audit2allow -R command (bug)

Add the following instead to mlogc.te to allow this access:

miscfiles_read_localization(mlogc_t)



>
>
>
> Thanks again for all your help!
>
> Cheers
>
> 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-08-2010, 01:27 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
> On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
> > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
> >
> > [snip]
> > >
> > > I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.
> > >
> > > This brings us to a security issue need to consider and deal with.
> > >
> > > As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.
> > >
> > > Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.
> > >
> > > So how can we deal with this? Well there are something we should investigate.
> > >
> > > Can we configure mod_security to use a custom location for its log files?
> > > Maybe we do not have to:
> > >
> > > Can you tell me which directories in /var/log/httpd are owned by mod_security?
> >
> > OK - Here is the story:
> >
> > I have been using mod-security for some time now with none of theses
> > shenanigans...
> >
> > Normally mod-security writes its logs to /var/log/httpd/ (the same place
> > as the apache logs) and there are only 2 files:
> > /var/log/httpd/modsec_audit.log
> > /var/log/httpd/modsec_debug.log
> >
> > The audit log being the main workhorse where each individual mod-sec
> > action was recorded.
> >
> > All of that was fine. mlogc was not involved.
> >
> > Recently, I decided to start using the Mod-Security Community Console, a
> > (java-based I think) web app for viewing, and giving more user-friendly
> > detail of, all the alerts produced by mod-sec.
> >
> > This requires a different approach to logging and this is where mlogc
> > comes in.
> >
> > Mod-security has two logging modes, serial and concurrent. "Serial"
> > places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
> > on the other hand, places log files in separate directories
> > corresponding to the time that the log was generated. This is what is
> > required by the Console app.
> >
> > This is configured from
> > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
> > the following directives:
> >
> > For Concurrent logging:-
> > SecAuditLogType Concurrent #(sets logging type)
> > SecDataDir /var/log/httpd/modsec_data # Sets log location
> > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
> > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
> >
> > For Serial Logging:-
> > #SecAuditLogType Serial
> > #SecAuditLog logs/modsec_audit.log
> >
> > Mlogc has its own configuration:
> > /etc/mlogc.conf
> >
> > I reproduce it in full here:
> >
> >
> > # cat /etc/mlogc.conf
> > ################################################## ########################
> > # Required configuration
> > # At a minimum, the items in this section will need to be adjusted to
> > # fit your environment. The remaining options are optional.
> > ################################################## ########################
> >
> > # Points to the root of the installation. All relative
> > # paths will be resolved with the help of this path.
> > CollectorRoot "/var/log/httpd/mlogc"
> >
> > # ModSecurity Console receiving URI. You can change the host
> > # and the port parts but leave everything else as is.
> > ConsoleURI "https://127.0.0.1:8888/rpc/auditLogReceiver"
> >
> > # Sensor credentials
> > SensorUsername "MCS"
> > SensorPassword "mypassword"
> >
> > # Base directory where the audit logs are stored. This can be specified
> > # as a path relative to the CollectorRoot, or a full path.
> > LogStorageDir "data"
> >
> > # Transaction log will contain the information on all log collector
> > # activities that happen between checkpoints. The transaction log
> > # is used to recover data in case of a crash (or if Apache kills
> > # the process).
> > TransactionLog "mlogc-transaction.log"
> >
> > # The file where the pending audit log entry data is kept. This file
> > # is updated on every checkpoint.
> > QueuePath "mlogc-queue.log"
> >
> > # The location of the error log.
> > ErrorLog "mlogc-error.log"
> >
> > # The location of the lock file.
> > LockFile "mlogc.lck"
> >
> > # Keep audit log entries after sending? (0=false 1=true)
> > # NOTE: This is required to be set in SecAuditLog mlogc config if you
> > # are going to use a secondary console via SecAuditLog2.
> > KeepEntries 0
> >
> >
> > ################################################## ########################
> > # Optional configuration
> > ################################################## ########################
> >
> > # The error log level controls how much detail there
> > # will be in the error log. The levels are as follows:
> > # 0 - NONE
> > # 1 - ERROR
> > # 2 - WARNING
> > # 3 - NOTICE
> > # 4 - DEBUG
> > # 5 - DEBUG2
> > #
> > ErrorLogLevel 3
> >
> > # How many concurrent connections to the server
> > # are we allowed to open at the same time? Log collector uses
> > # multiple connections in order to speed up audit log transfer.
> > # This is especially needed when the communication takes place
> > # over a slow link (e.g. not over a LAN).
> > MaxConnections 10
> >
> > # How many requests a worker will process before recycling itself.
> > # This is to help prevent problems due to any memory leaks that may
> > # exists. If this is set to 0, then no maximum is imposed. The default
> > # is 1000 requests per worker (the number of workers is controlled by
> > the
> > # MaxConnections limit).
> > MaxWorkerRequests 1000
> >
> > # The time each connection will sit idle before being reused,
> > # in milliseconds. Increase if you don't want ModSecurity Console
> > # to be hit with too many log collector requests.
> > TransactionDelay 50
> >
> > # The time to wait before initialization on startup in milliseconds.
> > # Increase if mlogc is starting faster then termination when the
> > # sensor is reloaded.
> > StartupDelay 5000
> >
> > # How often is the pending audit log entry data going to be written
> > # to a file. The default is 15 seconds.
> > CheckpointInterval 15
> >
> > # If the server fails all threads will back down until the
> > # problem is sorted. The management thread will periodically
> > # launch a thread to test the server. The default is to test
> > # once in 60 seconds.
> > ServerErrorTimeout 60
> >
> > # The following two parameters are not used yet, but
> > # reserved for future expansion.
> > # KeepAlive 150
> > # KeepAliveTimeout 300
> >
> > ################################################## ###############################
>
>
> Alright. I wonder why they put that location in httpd's log location. From a SELinux
> perspective it would makes things a bit simpler if they just set:
>
> SecAuditLogStorageDir /var/log/mlogc/data
> CollectorRoot "/var/log/mlogc"
> LogStorageDir "data"

Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
(that since it was all to do with httpd) it would be better (and cause
fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
don't hit me...!).

OK - I'll move it back...


>
> Then we can easily create a new log file type for mlogc log content in /var/log and set up a file type transition:
>
> mlogc.te:
>
> # declare a type and make the type usable for mlogc log content
> type mlogc_var_log_t;
> logging_log_file(mlogc_var_log_t;
>
> # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
> manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
>
> Next we add a file context specification for this in mlogc.fc:
>
> /var/log/mlogc(/.*)? gen_context(system_ubject_r:mlogc_var_log_t, s0)
>
> We should for now comment out or remove the "apache_manage_log(mlogc_t)" in mlogc.te that we added earlier for the time being.

Done all that...

> > I think most of that is self-explanatory. Note especially the ConsoleURI
> > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> > alerts into the Console which listens on port 8888, and this is the
> > answer to one of your later questions.
>
> I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?

OK - It's called modsecurity-console and it's located in /usr/local/bin
- but it's actually linked to /opt

# ll /usr/local/bin/modsecurity-console
lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console -> /opt/modsecurity-console/modsecurity-console

> >
> > Note however that I am also experimenting with another Console app (also
> > Java based, which does exactly the same thing in the same way) but in
> > this case listens on port 8443.
> >
> > >
> > > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > > This will benefit security as:
> > >
> > > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> > >
> > > We must try to find the best solution to the above securities issue so again: two questions:
> > >
> > > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
> >
> > The answer to 1 is yes as you can see above.
> > >
> > > > Raw Audit Messages :
> > > >
> > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> > >
> > > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> > >
> > > 1. Why is it connecting to the network?
> > > 2. What is listening on tcp:8888 on the other side?
> >
> > That's the Console app as described above.
> >
> > >
> > > We have to find some answers before we can start implementing a proper solution.
> >
> > [snip]
> >
> > > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> > >
> > > Add the following to your mlogc.te file:
> > >
> > > pcscd_read_pub_files(mlogc_t)
> > >
> > > That should allow mlogc_t to read pcscd pid files.
> >
> > Done that - thanks..
> >
> > >
> > > >
> > > >
> > > > And as I was copying the above, this one came in...
> > > >
> > > > Raw Audit Messages :
> > > >
> > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > > >
> > > >
> > >
> > > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> > >
> > >
> > > Now we are getting into the harder aspect of writing policy.
> > > Writing a template for a new domain and just allowing access is not so hard.
> > > What is harder is: making solid security decisions.
> > >
> > >
> > > What is it doing
> > > why is it doing it
> > > who is doing it to who
> > > Is this a threat
> > > why is it a threat
> > > how can we neutralize it?
> > >
> > > fun!
> >
> > For you maybe
> >
> > OK - I hope the above helps...
> >
> > By the way since my last message I have had another 71 AVcs - too many
> > to post, and doubtless many duplicates, but here is what audit2allow has
> > to say about them:
> >
> > # ausearch -m AVC -ts today | audit2allow -R
> >
> > require {
> > type mlogc_t;
> > type httpd_t;
> > class capability { sys_nice dac_override };
> > class process { setsched signal getsched };
> > class sem { read write create unix_write destroy };
> > }
> >
> > #============= httpd_t ==============
> > allow httpd_t mlogc_trocess signal;
>
> Ignore this for now, we might add it later.
>
> >
> > #============= mlogc_t ==============
> > allow mlogc_t self:capability { sys_nice dac_override };
>
> Did you figure out which location not owned by root mlogc is trying to access?
> For the moment lets ignore these.
>
> > allow mlogc_t selfrocess { setsched getsched };
>
> The above can be added to mlogc.te
>
> > allow mlogc_t self:sem { read write create unix_write destroy };
>
> Ignore for now
>
> > files_rw_etc_files(mlogc_t)

Done those...

> I suspect that mlogc_t is writing to its own configuration file but i cannot be sure until i see the avc denials
> related to this:
>
> ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write

That produced nothing:

# ausearch -m avc -ts today | grep mlogc_t | grep etc_t
type=AVC msg=audit(1270692897.579:45613): avc: denied { open } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
type=AVC msg=audit(1270692897.579:45613): avc: denied { read } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
type=AVC msg=audit(1270728056.690:46895): avc: denied { open } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
type=AVC msg=audit(1270728056.690:46895): avc: denied { read } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file


>
>
> > miscfiles_rw_localization(mlogc_t)
>
> This is a misinterpretation by the audit2allow -R command (bug)
>
> Add the following instead to mlogc.te to allow this access:
>
> miscfiles_read_localization(mlogc_t)

Done that...

Having done all that (including moving mlogc back to /var/log/mlogc)
these are the current AVCs (18 of them) since making the above changes:

# ausearch -m AVC -ts recent | audit2allow -R

require {
type var_log_t;
type httpd_log_t;
type pcscd_t;
type httpd_t;
type mlogc_t;
class capability dac_override;
class unix_stream_socket connectto;
class sem { read write unix_write };
class file { write rename unlink };
class dir create;
}

#============= httpd_t ==============
allow httpd_t httpd_log_t:file write;
allow httpd_t var_log_t:dir create;

#============= mlogc_t ==============
allow mlogc_t httpd_log_t:file { rename unlink };
allow mlogc_t pcscd_t:unix_stream_socket connectto;
allow mlogc_t self:capability dac_override;
allow mlogc_t self:sem { read write unix_write };
corenet_tcp_connect_generic_port(mlogc_t)
dev_read_urand(mlogc_t)
files_list_tmp(mlogc_t)
files_read_usr_symlinks(mlogc_t)
files_rw_etc_files(mlogc_t)
miscfiles_read_certs(mlogc_t)
pcscd_stream_connect(mlogc_t)

Phew!

Are we getting closer?

Thanks - yet again!

Mark



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

On Thu, Apr 08, 2010 at 02:27:02PM +0100, Arthur Dent wrote:
> On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
> > On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
> > > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
> > >
> > > [snip]
> > > >
> > > > I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.
> > > >
> > > > This brings us to a security issue need to consider and deal with.
> > > >
> > > > As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.
> > > >
> > > > Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.
> > > >
> > > > So how can we deal with this? Well there are something we should investigate.
> > > >
> > > > Can we configure mod_security to use a custom location for its log files?
> > > > Maybe we do not have to:
> > > >
> > > > Can you tell me which directories in /var/log/httpd are owned by mod_security?
> > >
> > > OK - Here is the story:
> > >
> > > I have been using mod-security for some time now with none of theses
> > > shenanigans...
> > >
> > > Normally mod-security writes its logs to /var/log/httpd/ (the same place
> > > as the apache logs) and there are only 2 files:
> > > /var/log/httpd/modsec_audit.log
> > > /var/log/httpd/modsec_debug.log
> > >
> > > The audit log being the main workhorse where each individual mod-sec
> > > action was recorded.
> > >
> > > All of that was fine. mlogc was not involved.
> > >
> > > Recently, I decided to start using the Mod-Security Community Console, a
> > > (java-based I think) web app for viewing, and giving more user-friendly
> > > detail of, all the alerts produced by mod-sec.
> > >
> > > This requires a different approach to logging and this is where mlogc
> > > comes in.
> > >
> > > Mod-security has two logging modes, serial and concurrent. "Serial"
> > > places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
> > > on the other hand, places log files in separate directories
> > > corresponding to the time that the log was generated. This is what is
> > > required by the Console app.
> > >
> > > This is configured from
> > > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
> > > the following directives:
> > >
> > > For Concurrent logging:-
> > > SecAuditLogType Concurrent #(sets logging type)
> > > SecDataDir /var/log/httpd/modsec_data # Sets log location
> > > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
> > > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
> > >
> > > For Serial Logging:-
> > > #SecAuditLogType Serial
> > > #SecAuditLog logs/modsec_audit.log
> > >
> > > Mlogc has its own configuration:
> > > /etc/mlogc.conf
> > >
> > > I reproduce it in full here:
> > >
> > >
> > > # cat /etc/mlogc.conf
> > > ################################################## ########################
> > > # Required configuration
> > > # At a minimum, the items in this section will need to be adjusted to
> > > # fit your environment. The remaining options are optional.
> > > ################################################## ########################
> > >
> > > # Points to the root of the installation. All relative
> > > # paths will be resolved with the help of this path.
> > > CollectorRoot "/var/log/httpd/mlogc"
> > >
> > > # ModSecurity Console receiving URI. You can change the host
> > > # and the port parts but leave everything else as is.
> > > ConsoleURI "https://127.0.0.1:8888/rpc/auditLogReceiver"
> > >
> > > # Sensor credentials
> > > SensorUsername "MCS"
> > > SensorPassword "mypassword"
> > >
> > > # Base directory where the audit logs are stored. This can be specified
> > > # as a path relative to the CollectorRoot, or a full path.
> > > LogStorageDir "data"
> > >
> > > # Transaction log will contain the information on all log collector
> > > # activities that happen between checkpoints. The transaction log
> > > # is used to recover data in case of a crash (or if Apache kills
> > > # the process).
> > > TransactionLog "mlogc-transaction.log"
> > >
> > > # The file where the pending audit log entry data is kept. This file
> > > # is updated on every checkpoint.
> > > QueuePath "mlogc-queue.log"
> > >
> > > # The location of the error log.
> > > ErrorLog "mlogc-error.log"
> > >
> > > # The location of the lock file.
> > > LockFile "mlogc.lck"
> > >
> > > # Keep audit log entries after sending? (0=false 1=true)
> > > # NOTE: This is required to be set in SecAuditLog mlogc config if you
> > > # are going to use a secondary console via SecAuditLog2.
> > > KeepEntries 0
> > >
> > >
> > > ################################################## ########################
> > > # Optional configuration
> > > ################################################## ########################
> > >
> > > # The error log level controls how much detail there
> > > # will be in the error log. The levels are as follows:
> > > # 0 - NONE
> > > # 1 - ERROR
> > > # 2 - WARNING
> > > # 3 - NOTICE
> > > # 4 - DEBUG
> > > # 5 - DEBUG2
> > > #
> > > ErrorLogLevel 3
> > >
> > > # How many concurrent connections to the server
> > > # are we allowed to open at the same time? Log collector uses
> > > # multiple connections in order to speed up audit log transfer.
> > > # This is especially needed when the communication takes place
> > > # over a slow link (e.g. not over a LAN).
> > > MaxConnections 10
> > >
> > > # How many requests a worker will process before recycling itself.
> > > # This is to help prevent problems due to any memory leaks that may
> > > # exists. If this is set to 0, then no maximum is imposed. The default
> > > # is 1000 requests per worker (the number of workers is controlled by
> > > the
> > > # MaxConnections limit).
> > > MaxWorkerRequests 1000
> > >
> > > # The time each connection will sit idle before being reused,
> > > # in milliseconds. Increase if you don't want ModSecurity Console
> > > # to be hit with too many log collector requests.
> > > TransactionDelay 50
> > >
> > > # The time to wait before initialization on startup in milliseconds.
> > > # Increase if mlogc is starting faster then termination when the
> > > # sensor is reloaded.
> > > StartupDelay 5000
> > >
> > > # How often is the pending audit log entry data going to be written
> > > # to a file. The default is 15 seconds.
> > > CheckpointInterval 15
> > >
> > > # If the server fails all threads will back down until the
> > > # problem is sorted. The management thread will periodically
> > > # launch a thread to test the server. The default is to test
> > > # once in 60 seconds.
> > > ServerErrorTimeout 60
> > >
> > > # The following two parameters are not used yet, but
> > > # reserved for future expansion.
> > > # KeepAlive 150
> > > # KeepAliveTimeout 300
> > >
> > > ################################################## ###############################
> >
> >
> > Alright. I wonder why they put that location in httpd's log location. From a SELinux
> > perspective it would makes things a bit simpler if they just set:
> >
> > SecAuditLogStorageDir /var/log/mlogc/data
> > CollectorRoot "/var/log/mlogc"
> > LogStorageDir "data"
>
> Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
> (that since it was all to do with httpd) it would be better (and cause
> fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
> don't hit me...!).
>
> OK - I'll move it back...
>
>
> >
> > Then we can easily create a new log file type for mlogc log content in /var/log and set up a file type transition:
> >
> > mlogc.te:
> >
> > # declare a type and make the type usable for mlogc log content
> > type mlogc_var_log_t;
> > logging_log_file(mlogc_var_log_t;
> >
> > # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
> > manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> > manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> > logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
> >
> > Next we add a file context specification for this in mlogc.fc:
> >
> > /var/log/mlogc(/.*)? gen_context(system_ubject_r:mlogc_var_log_t, s0)
> >
> > We should for now comment out or remove the "apache_manage_log(mlogc_t)" in mlogc.te that we added earlier for the time being.
>
> Done all that...

I hope you noticed the typo i made here:

was:
logging_log_file(mlogc_var_log_t;

should be:
logging_log_file(mlogc_var_log_t)

>
> > > I think most of that is self-explanatory. Note especially the ConsoleURI
> > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> > > alerts into the Console which listens on port 8888, and this is the
> > > answer to one of your later questions.
> >
> > I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?
>
> OK - It's called modsecurity-console and it's located in /usr/local/bin
> - but it's actually linked to /opt

What runs it? You the user or is it an init daemon.

Since it is using odd paths i asume there is no redhat rpm?

>
> # ll /usr/local/bin/modsecurity-console
> lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console -> /opt/modsecurity-console/modsecurity-console
>
> > >
> > > Note however that I am also experimenting with another Console app (also
> > > Java based, which does exactly the same thing in the same way) but in
> > > this case listens on port 8443.
> > >
> > > >
> > > > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > > > This will benefit security as:
> > > >
> > > > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > > > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> > > >
> > > > We must try to find the best solution to the above securities issue so again: two questions:
> > > >
> > > > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > > > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
> > >
> > > The answer to 1 is yes as you can see above.
> > > >
> > > > > Raw Audit Messages :
> > > > >
> > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> > > >
> > > > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> > > >
> > > > 1. Why is it connecting to the network?
> > > > 2. What is listening on tcp:8888 on the other side?
> > >
> > > That's the Console app as described above.
> > >
> > > >
> > > > We have to find some answers before we can start implementing a proper solution.
> > >
> > > [snip]
> > >
> > > > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> > > >
> > > > Add the following to your mlogc.te file:
> > > >
> > > > pcscd_read_pub_files(mlogc_t)
> > > >
> > > > That should allow mlogc_t to read pcscd pid files.
> > >
> > > Done that - thanks..
> > >
> > > >
> > > > >
> > > > >
> > > > > And as I was copying the above, this one came in...
> > > > >
> > > > > Raw Audit Messages :
> > > > >
> > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > > > >
> > > > >
> > > >
> > > > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> > > >
> > > >
> > > > Now we are getting into the harder aspect of writing policy.
> > > > Writing a template for a new domain and just allowing access is not so hard.
> > > > What is harder is: making solid security decisions.
> > > >
> > > >
> > > > What is it doing
> > > > why is it doing it
> > > > who is doing it to who
> > > > Is this a threat
> > > > why is it a threat
> > > > how can we neutralize it?
> > > >
> > > > fun!
> > >
> > > For you maybe
> > >
> > > OK - I hope the above helps...
> > >
> > > By the way since my last message I have had another 71 AVcs - too many
> > > to post, and doubtless many duplicates, but here is what audit2allow has
> > > to say about them:
> > >
> > > # ausearch -m AVC -ts today | audit2allow -R
> > >
> > > require {
> > > type mlogc_t;
> > > type httpd_t;
> > > class capability { sys_nice dac_override };
> > > class process { setsched signal getsched };
> > > class sem { read write create unix_write destroy };
> > > }
> > >
> > > #============= httpd_t ==============
> > > allow httpd_t mlogc_trocess signal;
> >
> > Ignore this for now, we might add it later.
> >
> > >
> > > #============= mlogc_t ==============
> > > allow mlogc_t self:capability { sys_nice dac_override };
> >
> > Did you figure out which location not owned by root mlogc is trying to access?
> > For the moment lets ignore these.
> >
> > > allow mlogc_t selfrocess { setsched getsched };
> >
> > The above can be added to mlogc.te
> >
> > > allow mlogc_t self:sem { read write create unix_write destroy };
> >
> > Ignore for now
> >
> > > files_rw_etc_files(mlogc_t)

The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it

instead add the following to mlogc.te:

type mlogc_etc_t;
files_config_file(mlogc_etc_t)

read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
files_search_etc(mlogc_t)

And add to mlogc.fc:

/etc/mlogc.conf -- gen_context(system_ubject_r:mlogc_etc_t, s0)

> Done those...
>
> > I suspect that mlogc_t is writing to its own configuration file but i cannot be sure until i see the avc denials
> > related to this:
> >
> > ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write
>
> That produced nothing:
>
> # ausearch -m avc -ts today | grep mlogc_t | grep etc_t
> type=AVC msg=audit(1270692897.579:45613): avc: denied { open } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270692897.579:45613): avc: denied { read } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270728056.690:46895): avc: denied { open } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270728056.690:46895): avc: denied { read } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
>
>
> >
> >
> > > miscfiles_rw_localization(mlogc_t)
> >
> > This is a misinterpretation by the audit2allow -R command (bug)
> >
> > Add the following instead to mlogc.te to allow this access:
> >
> > miscfiles_read_localization(mlogc_t)
>
> Done that...
>
> Having done all that (including moving mlogc back to /var/log/mlogc)
> these are the current AVCs (18 of them) since making the above changes:
>
> # ausearch -m AVC -ts recent | audit2allow -R
>
> require {
> type var_log_t;
> type httpd_log_t;
> type pcscd_t;
> type httpd_t;
> type mlogc_t;
> class capability dac_override;
> class unix_stream_socket connectto;
> class sem { read write unix_write };
> class file { write rename unlink };
> class dir create;
> }
>
> #============= httpd_t ==============
> allow httpd_t httpd_log_t:file write;
> allow httpd_t var_log_t:dir create;

ignore above for now

>
> #============= mlogc_t ==============
> allow mlogc_t httpd_log_t:file { rename unlink };
> allow mlogc_t pcscd_t:unix_stream_socket connectto;
> allow mlogc_t self:capability dac_override;
> allow mlogc_t self:sem { read write unix_write };
> corenet_tcp_connect_generic_port(mlogc_t)

ignore above for now.

> dev_read_urand(mlogc_t)

add above to mlogc.te

> files_list_tmp(mlogc_t)

ignore above for now. need to figure out why its listing tmp, what is it hoping to list?

> files_read_usr_symlinks(mlogc_t)

not sure why it wants the above but its harmless, so can add it to mlogc.te for now

> files_rw_etc_files(mlogc_t)

This is a bug in audit2allow. We added proper rules above so ignore this.

> miscfiles_read_certs(mlogc_t)
> pcscd_stream_connect(mlogc_t)

The above can be added to mlogc.te

We need to figure out how to deal with that console app. need to figure out what runs it and what files it owns.

>
> Phew!
>
> Are we getting closer?

Well closer i do not know. we are advancing.

>
> Thanks - yet again!
>
> 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-08-2010, 02:41 PM
Dominick Grift
 
Default Mod-security (mlogc) problem

On Thu, Apr 08, 2010 at 02:27:02PM +0100, Arthur Dent wrote:
> On Thu, 2010-04-08 at 11:35 +0200, Dominick Grift wrote:
> > On Thu, Apr 08, 2010 at 09:40:41AM +0100, Arthur Dent wrote:
> > > On Thu, 2010-04-08 at 08:42 +0200, Dominick Grift wrote:
> > >
> > > [snip]
> > > >
> > > > I gather that these access vectors denials are caused by the actual mod_security module. Since the source in the interaction is the httpd programs.
> > > >
> > > > This brings us to a security issue need to consider and deal with.
> > > >
> > > > As you can see: httpd_t is not allowed to create directories with type httpd_log_t and is not allowed to write to files with type httpd_log_t. This is because normally it does not need this permissions.
> > > >
> > > > Httpd_t writing to its log file is a bad idea. Consider for example a cracker compromizing the web server trying to erase his audit trail by removing entries from the httpd log files.
> > > >
> > > > So how can we deal with this? Well there are something we should investigate.
> > > >
> > > > Can we configure mod_security to use a custom location for its log files?
> > > > Maybe we do not have to:
> > > >
> > > > Can you tell me which directories in /var/log/httpd are owned by mod_security?
> > >
> > > OK - Here is the story:
> > >
> > > I have been using mod-security for some time now with none of theses
> > > shenanigans...
> > >
> > > Normally mod-security writes its logs to /var/log/httpd/ (the same place
> > > as the apache logs) and there are only 2 files:
> > > /var/log/httpd/modsec_audit.log
> > > /var/log/httpd/modsec_debug.log
> > >
> > > The audit log being the main workhorse where each individual mod-sec
> > > action was recorded.
> > >
> > > All of that was fine. mlogc was not involved.
> > >
> > > Recently, I decided to start using the Mod-Security Community Console, a
> > > (java-based I think) web app for viewing, and giving more user-friendly
> > > detail of, all the alerts produced by mod-sec.
> > >
> > > This requires a different approach to logging and this is where mlogc
> > > comes in.
> > >
> > > Mod-security has two logging modes, serial and concurrent. "Serial"
> > > places all alerts in the above mod-sec.audit.log. "Concurrent" logging,
> > > on the other hand, places log files in separate directories
> > > corresponding to the time that the log was generated. This is what is
> > > required by the Console app.
> > >
> > > This is configured from
> > > the /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file with
> > > the following directives:
> > >
> > > For Concurrent logging:-
> > > SecAuditLogType Concurrent #(sets logging type)
> > > SecDataDir /var/log/httpd/modsec_data # Sets log location
> > > SecAuditLogStorageDir /var/log/httpd/mlogc/data # Location for for detailed logs
> > > SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" # Pipes the alerts to mlogc
> > >
> > > For Serial Logging:-
> > > #SecAuditLogType Serial
> > > #SecAuditLog logs/modsec_audit.log
> > >
> > > Mlogc has its own configuration:
> > > /etc/mlogc.conf
> > >
> > > I reproduce it in full here:
> > >
> > >
> > > # cat /etc/mlogc.conf
> > > ################################################## ########################
> > > # Required configuration
> > > # At a minimum, the items in this section will need to be adjusted to
> > > # fit your environment. The remaining options are optional.
> > > ################################################## ########################
> > >
> > > # Points to the root of the installation. All relative
> > > # paths will be resolved with the help of this path.
> > > CollectorRoot "/var/log/httpd/mlogc"
> > >
> > > # ModSecurity Console receiving URI. You can change the host
> > > # and the port parts but leave everything else as is.
> > > ConsoleURI "https://127.0.0.1:8888/rpc/auditLogReceiver"
> > >
> > > # Sensor credentials
> > > SensorUsername "MCS"
> > > SensorPassword "mypassword"
> > >
> > > # Base directory where the audit logs are stored. This can be specified
> > > # as a path relative to the CollectorRoot, or a full path.
> > > LogStorageDir "data"
> > >
> > > # Transaction log will contain the information on all log collector
> > > # activities that happen between checkpoints. The transaction log
> > > # is used to recover data in case of a crash (or if Apache kills
> > > # the process).
> > > TransactionLog "mlogc-transaction.log"
> > >
> > > # The file where the pending audit log entry data is kept. This file
> > > # is updated on every checkpoint.
> > > QueuePath "mlogc-queue.log"
> > >
> > > # The location of the error log.
> > > ErrorLog "mlogc-error.log"
> > >
> > > # The location of the lock file.
> > > LockFile "mlogc.lck"
> > >
> > > # Keep audit log entries after sending? (0=false 1=true)
> > > # NOTE: This is required to be set in SecAuditLog mlogc config if you
> > > # are going to use a secondary console via SecAuditLog2.
> > > KeepEntries 0
> > >
> > >
> > > ################################################## ########################
> > > # Optional configuration
> > > ################################################## ########################
> > >
> > > # The error log level controls how much detail there
> > > # will be in the error log. The levels are as follows:
> > > # 0 - NONE
> > > # 1 - ERROR
> > > # 2 - WARNING
> > > # 3 - NOTICE
> > > # 4 - DEBUG
> > > # 5 - DEBUG2
> > > #
> > > ErrorLogLevel 3
> > >
> > > # How many concurrent connections to the server
> > > # are we allowed to open at the same time? Log collector uses
> > > # multiple connections in order to speed up audit log transfer.
> > > # This is especially needed when the communication takes place
> > > # over a slow link (e.g. not over a LAN).
> > > MaxConnections 10
> > >
> > > # How many requests a worker will process before recycling itself.
> > > # This is to help prevent problems due to any memory leaks that may
> > > # exists. If this is set to 0, then no maximum is imposed. The default
> > > # is 1000 requests per worker (the number of workers is controlled by
> > > the
> > > # MaxConnections limit).
> > > MaxWorkerRequests 1000
> > >
> > > # The time each connection will sit idle before being reused,
> > > # in milliseconds. Increase if you don't want ModSecurity Console
> > > # to be hit with too many log collector requests.
> > > TransactionDelay 50
> > >
> > > # The time to wait before initialization on startup in milliseconds.
> > > # Increase if mlogc is starting faster then termination when the
> > > # sensor is reloaded.
> > > StartupDelay 5000
> > >
> > > # How often is the pending audit log entry data going to be written
> > > # to a file. The default is 15 seconds.
> > > CheckpointInterval 15
> > >
> > > # If the server fails all threads will back down until the
> > > # problem is sorted. The management thread will periodically
> > > # launch a thread to test the server. The default is to test
> > > # once in 60 seconds.
> > > ServerErrorTimeout 60
> > >
> > > # The following two parameters are not used yet, but
> > > # reserved for future expansion.
> > > # KeepAlive 150
> > > # KeepAliveTimeout 300
> > >
> > > ################################################## ###############################
> >
> >
> > Alright. I wonder why they put that location in httpd's log location. From a SELinux
> > perspective it would makes things a bit simpler if they just set:
> >
> > SecAuditLogStorageDir /var/log/mlogc/data
> > CollectorRoot "/var/log/mlogc"
> > LogStorageDir "data"
>
> Ermmm... Sorry - That was my fault. It WAS in var/log/mlog/ I thought
> (that since it was all to do with httpd) it would be better (and cause
> fewr SEL AVCs) if I moved it to /var/log/http/mlogc (cringe... sorry...
> don't hit me...!).
>
> OK - I'll move it back...
>
>
> >
> > Then we can easily create a new log file type for mlogc log content in /var/log and set up a file type transition:
> >
> > mlogc.te:
> >
> > # declare a type and make the type usable for mlogc log content
> > type mlogc_var_log_t;
> > logging_log_file(mlogc_var_log_t;
> >
> > # allow mlogc to manage and create content in /var/log with type mlogc_var_log_t:
> > manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> > manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> > logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
> >
> > Next we add a file context specification for this in mlogc.fc:
> >
> > /var/log/mlogc(/.*)? gen_context(system_ubject_r:mlogc_var_log_t, s0)
> >
> > We should for now comment out or remove the "apache_manage_log(mlogc_t)" in mlogc.te that we added earlier for the time being.
>
> Done all that...
>
> > > I think most of that is self-explanatory. Note especially the ConsoleURI
> > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> > > alerts into the Console which listens on port 8888, and this is the
> > > answer to one of your later questions.
> >
> > I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?
>
> OK - It's called modsecurity-console and it's located in /usr/local/bin
> - but it's actually linked to /opt
>
> # ll /usr/local/bin/modsecurity-console
> lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console -> /opt/modsecurity-console/modsecurity-console
>
> > >
> > > Note however that I am also experimenting with another Console app (also
> > > Java based, which does exactly the same thing in the same way) but in
> > > this case listens on port 8443.
> > >
> > > >
> > > > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > > > This will benefit security as:
> > > >
> > > > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > > > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> > > >
> > > > We must try to find the best solution to the above securities issue so again: two questions:
> > > >
> > > > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > > > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
> > >
> > > The answer to 1 is yes as you can see above.
> > > >
> > > > > Raw Audit Messages :
> > > > >
> > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> > > >
> > > > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> > > >
> > > > 1. Why is it connecting to the network?
> > > > 2. What is listening on tcp:8888 on the other side?
> > >
> > > That's the Console app as described above.
> > >
> > > >
> > > > We have to find some answers before we can start implementing a proper solution.
> > >
> > > [snip]
> > >
> > > > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> > > >
> > > > Add the following to your mlogc.te file:
> > > >
> > > > pcscd_read_pub_files(mlogc_t)
> > > >
> > > > That should allow mlogc_t to read pcscd pid files.
> > >
> > > Done that - thanks..
> > >
> > > >
> > > > >
> > > > >
> > > > > And as I was copying the above, this one came in...
> > > > >
> > > > > Raw Audit Messages :
> > > > >
> > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > > > >
> > > > >
> > > >
> > > > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> > > >
> > > >
> > > > Now we are getting into the harder aspect of writing policy.
> > > > Writing a template for a new domain and just allowing access is not so hard.
> > > > What is harder is: making solid security decisions.
> > > >
> > > >
> > > > What is it doing
> > > > why is it doing it
> > > > who is doing it to who
> > > > Is this a threat
> > > > why is it a threat
> > > > how can we neutralize it?
> > > >
> > > > fun!
> > >
> > > For you maybe
> > >
> > > OK - I hope the above helps...
> > >
> > > By the way since my last message I have had another 71 AVcs - too many
> > > to post, and doubtless many duplicates, but here is what audit2allow has
> > > to say about them:
> > >
> > > # ausearch -m AVC -ts today | audit2allow -R
> > >
> > > require {
> > > type mlogc_t;
> > > type httpd_t;
> > > class capability { sys_nice dac_override };
> > > class process { setsched signal getsched };
> > > class sem { read write create unix_write destroy };
> > > }
> > >
> > > #============= httpd_t ==============
> > > allow httpd_t mlogc_trocess signal;
> >
> > Ignore this for now, we might add it later.
> >
> > >
> > > #============= mlogc_t ==============
> > > allow mlogc_t self:capability { sys_nice dac_override };
> >
> > Did you figure out which location not owned by root mlogc is trying to access?
> > For the moment lets ignore these.
> >
> > > allow mlogc_t selfrocess { setsched getsched };
> >
> > The above can be added to mlogc.te
> >
> > > allow mlogc_t self:sem { read write create unix_write destroy };
> >
> > Ignore for now
> >
> > > files_rw_etc_files(mlogc_t)
>
> Done those...
>
> > I suspect that mlogc_t is writing to its own configuration file but i cannot be sure until i see the avc denials
> > related to this:
> >
> > ausearch -m avc -ts today | grep mlogc_t | grep etc_t | grep write
>
> That produced nothing:
>
> # ausearch -m avc -ts today | grep mlogc_t | grep etc_t
> type=AVC msg=audit(1270692897.579:45613): avc: denied { open } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270692897.579:45613): avc: denied { read } for pid=6645 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233394 scontext=system_u:system_r:mlogc_t:s0-s0:c0.c1023 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270728056.690:46895): avc: denied { open } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
> type=AVC msg=audit(1270728056.690:46895): avc: denied { read } for pid=10851 comm="mlogc" name="mlogc.conf" dev=sda5 ino=1233510 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_r:etc_t:s0 tclass=file
>
>
> >
> >
> > > miscfiles_rw_localization(mlogc_t)
> >
> > This is a misinterpretation by the audit2allow -R command (bug)
> >
> > Add the following instead to mlogc.te to allow this access:
> >
> > miscfiles_read_localization(mlogc_t)
>
> Done that...
>
> Having done all that (including moving mlogc back to /var/log/mlogc)
> these are the current AVCs (18 of them) since making the above changes:
>
> # ausearch -m AVC -ts recent | audit2allow -R
>
> require {
> type var_log_t;
> type httpd_log_t;
> type pcscd_t;
> type httpd_t;
> type mlogc_t;
> class capability dac_override;
> class unix_stream_socket connectto;
> class sem { read write unix_write };
> class file { write rename unlink };
> class dir create;
> }
>
> #============= httpd_t ==============
> allow httpd_t httpd_log_t:file write;
> allow httpd_t var_log_t:dir create;

As for above. Make sure that file in question is labelled properly. Again httpd_t should not need to write to its log files. Neither should mod_security. I also have mod_security running on a server and it does not need to
write to log files (only append)

So we may end up silencing that denial.

As for httpd_t creating a dir in /var/log: I would like to see the denial. I was expecting mlogc to create
/var/log/mlogc.

>
> #============= mlogc_t ==============
> allow mlogc_t httpd_log_t:file { rename unlink };
> allow mlogc_t pcscd_t:unix_stream_socket connectto;
> allow mlogc_t self:capability dac_override;
> allow mlogc_t self:sem { read write unix_write };

> corenet_tcp_connect_generic_port(mlogc_t)

Alright, well i assume the "console app" is a user app that is started by you, the unconfined user.
I guess in that case we must allow mlogc to connect to any generic port. A bit coarse for my taste but so be it.

Add the following to all mlogc to connect to generic tcp ports in mlogc.te:

corenet_all_recvfrom_netlabel(mlogc_t)
corenet_all_recvfrom_unlabeled(mlogc_t)
corenet_tcp_sendrecv_generic_if(mlogc_t)
corenet_tcp_sendrecv_generic_node(mlogc_t)
corenet_tcp_sendrecv_generic_port(mlogc_t)
corenet_tcp_bind_generic_node(mlogc_t)
corenet_sendrecv_generic_client_packets(mlogc_t)
corenet_tcp_connect_generic_port(mlogc_t)

> dev_read_urand(mlogc_t)
> files_list_tmp(mlogc_t)
> files_read_usr_symlinks(mlogc_t)
> files_rw_etc_files(mlogc_t)
> miscfiles_read_certs(mlogc_t)
> pcscd_stream_connect(mlogc_t)
>
> Phew!
>
> Are we getting closer?
>
> Thanks - yet again!
>
> 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-08-2010, 02:50 PM
Arthur Dent
 
Default Mod-security (mlogc) problem

On Thu, 2010-04-08 at 16:09 +0200, Dominick Grift wrote:

> > Done all that...
>
> I hope you noticed the typo i made here:
>
> was:
> logging_log_file(mlogc_var_log_t;
>
> should be:
> logging_log_file(mlogc_var_log_t)

Yes, I caught that one. By the way, is a semicolon required after every
line?

>
> >
> > > > I think most of that is self-explanatory. Note especially the ConsoleURI
> > > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> > > > alerts into the Console which listens on port 8888, and this is the
> > > > answer to one of your later questions.
> > >
> > > I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?
> >
> > OK - It's called modsecurity-console and it's located in /usr/local/bin
> > - but it's actually linked to /opt
>
> What runs it? You the user or is it an init daemon.

Yes, at the moment I start it manually or with a cron job
(@reboot /usr/local/bin/modsecurity-console start) although i was
planning to make an init.d script for it given time..

>
> Since it is using odd paths i asume there is no redhat rpm?

No, This is an RPM, but from Breach Security - the authors. I also
installed it from source previously.

> >
> > # ll /usr/local/bin/modsecurity-console
> > lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console -> /opt/modsecurity-console/modsecurity-console
> >
> > > >
> > > > Note however that I am also experimenting with another Console app (also
> > > > Java based, which does exactly the same thing in the same way) but in
> > > > this case listens on port 8443.
> > > >
> > > > >
> > > > > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > > > > This will benefit security as:
> > > > >
> > > > > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > > > > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> > > > >
> > > > > We must try to find the best solution to the above securities issue so again: two questions:
> > > > >
> > > > > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > > > > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
> > > >
> > > > The answer to 1 is yes as you can see above.
> > > > >
> > > > > > Raw Audit Messages :
> > > > > >
> > > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> > > > >
> > > > > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> > > > >
> > > > > 1. Why is it connecting to the network?
> > > > > 2. What is listening on tcp:8888 on the other side?
> > > >
> > > > That's the Console app as described above.
> > > >
> > > > >
> > > > > We have to find some answers before we can start implementing a proper solution.
> > > >
> > > > [snip]
> > > >
> > > > > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> > > > >
> > > > > Add the following to your mlogc.te file:
> > > > >
> > > > > pcscd_read_pub_files(mlogc_t)
> > > > >
> > > > > That should allow mlogc_t to read pcscd pid files.
> > > >
> > > > Done that - thanks..
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > And as I was copying the above, this one came in...
> > > > > >
> > > > > > Raw Audit Messages :
> > > > > >
> > > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > > > > >
> > > > > >
> > > > >
> > > > > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> > > > >
> > > > >
> > > > > Now we are getting into the harder aspect of writing policy.
> > > > > Writing a template for a new domain and just allowing access is not so hard.
> > > > > What is harder is: making solid security decisions.
> > > > >
> > > > >
> > > > > What is it doing
> > > > > why is it doing it
> > > > > who is doing it to who
> > > > > Is this a threat
> > > > > why is it a threat
> > > > > how can we neutralize it?
> > > > >
> > > > > fun!
> > > >
> > > > For you maybe
> > > >
> > > > OK - I hope the above helps...
> > > >
> > > > By the way since my last message I have had another 71 AVcs - too many
> > > > to post, and doubtless many duplicates, but here is what audit2allow has
> > > > to say about them:
> > > >
> > > > # ausearch -m AVC -ts today | audit2allow -R
> > > >
> > > > require {
> > > > type mlogc_t;
> > > > type httpd_t;
> > > > class capability { sys_nice dac_override };
> > > > class process { setsched signal getsched };
> > > > class sem { read write create unix_write destroy };
> > > > }
> > > >
> > > > #============= httpd_t ==============
> > > > allow httpd_t mlogc_trocess signal;
> > >
> > > Ignore this for now, we might add it later.
> > >
> > > >
> > > > #============= mlogc_t ==============
> > > > allow mlogc_t self:capability { sys_nice dac_override };
> > >
> > > Did you figure out which location not owned by root mlogc is trying to access?
> > > For the moment lets ignore these.
> > >
> > > > allow mlogc_t selfrocess { setsched getsched };
> > >
> > > The above can be added to mlogc.te
> > >
> > > > allow mlogc_t self:sem { read write create unix_write destroy };
> > >
> > > Ignore for now
> > >
> > > > files_rw_etc_files(mlogc_t)
>
> The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it

Nope. You didn't tell me to add it so I didn't. I only do what I'm
told

>
> instead add the following to mlogc.te:
>
> type mlogc_etc_t;
> files_config_file(mlogc_etc_t)
> read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
> files_search_etc(mlogc_t)

Done.

> And add to mlogc.fc:
>
> /etc/mlogc.conf -- gen_context(system_ubject_r:mlogc_etc_t, s0)

Done.


> > Having done all that (including moving mlogc back to /var/log/mlogc)
> > these are the current AVCs (18 of them) since making the above changes:
> >
> > # ausearch -m AVC -ts recent | audit2allow -R
> >
> > require {
> > type var_log_t;
> > type httpd_log_t;
> > type pcscd_t;
> > type httpd_t;
> > type mlogc_t;
> > class capability dac_override;
> > class unix_stream_socket connectto;
> > class sem { read write unix_write };
> > class file { write rename unlink };
> > class dir create;
> > }
> >
> > #============= httpd_t ==============
> > allow httpd_t httpd_log_t:file write;
> > allow httpd_t var_log_t:dir create;
>
> ignore above for now
>
> >
> > #============= mlogc_t ==============
> > allow mlogc_t httpd_log_t:file { rename unlink };
> > allow mlogc_t pcscd_t:unix_stream_socket connectto;
> > allow mlogc_t self:capability dac_override;
> > allow mlogc_t self:sem { read write unix_write };
> > corenet_tcp_connect_generic_port(mlogc_t)
>
> ignore above for now.
>
> > dev_read_urand(mlogc_t)
>
> add above to mlogc.te

Done.

> > files_list_tmp(mlogc_t)
>
> ignore above for now. need to figure out why its listing tmp, what is it hoping to list?
>
> > files_read_usr_symlinks(mlogc_t)
>
> not sure why it wants the above but its harmless, so can add it to mlogc.te for now

Done.

> > files_rw_etc_files(mlogc_t)
>
> This is a bug in audit2allow. We added proper rules above so ignore this.
>
> > miscfiles_read_certs(mlogc_t)
> > pcscd_stream_connect(mlogc_t)
>
> The above can be added to mlogc.te

Done.


OK - Let's see what that brings...

Oops:
# make -f /usr/share/selinux/devel/Makefile
Compiling targeted mlogc module
/usr/bin/checkmodule: loading policy configuration from tmp/mlogc.tmp
mlogc.te":16:ERROR 'unknown type mlogc_etc_t' at token ';' on line 3828:
typeattribute mlogc_etc_t etcfile;
#line 16
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/mlogc.mod] Error 1

Is this the problem?
read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
2 x mlogc_etc_t ? Should that be something else or just 1 x ?

Here is the current mlogc.te

# cat mlogc.te
policy_module(mlogc, 1.0.3)

type mlogc_t;
type mlogc_exec_t;
type mlogc_var_log_t;

logging_log_file(mlogc_var_log_t);
logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
application_domain(mlogc_t, mlogc_exec_t);
role system_r types mlogc_t;
permissive mlogc_t;
manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
files_search_etc(mlogc_t)
files_config_file(mlogc_etc_t)
files_read_usr_symlinks(mlogc_t)
pcscd_read_pub_files(mlogc_t);
pcscd_stream_connect(mlogc_t)
miscfiles_read_localization(mlogc_t)
miscfiles_read_certs(mlogc_t)
dev_read_urand(mlogc_t)
#apache_manage_log(mlogc_t);

allow mlogc_t self:tcp_socket create_socket_perms;
allow mlogc_t self:udp_socket create_socket_perms;
allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;
allow mlogc_t selfrocess { setsched getsched };





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

On Thu, Apr 08, 2010 at 03:50:17PM +0100, Arthur Dent wrote:
> On Thu, 2010-04-08 at 16:09 +0200, Dominick Grift wrote:
>
> > > Done all that...
> >
> > I hope you noticed the typo i made here:
> >
> > was:
> > logging_log_file(mlogc_var_log_t;
> >
> > should be:
> > logging_log_file(mlogc_var_log_t)
>
> Yes, I caught that one. By the way, is a semicolon required after every
> line?

Yes pretty much, unless it end with a ) like logging_log_file(mlogc_var_log_t)
>
> >
> > >
> > > > > I think most of that is self-explanatory. Note especially the ConsoleURI
> > > > > "https://127.0.0.1:8888/rpc/auditLogReceiver" directive. This punts the
> > > > > alerts into the Console which listens on port 8888, and this is the
> > > > > answer to one of your later questions.
> > > >
> > > > I think we should also confine this "server". Which package includes this? what is the name/location of the executable file for this service?
> > >
> > > OK - It's called modsecurity-console and it's located in /usr/local/bin
> > > - but it's actually linked to /opt
> >
> > What runs it? You the user or is it an init daemon.
>
> Yes, at the moment I start it manually or with a cron job
> (@reboot /usr/local/bin/modsecurity-console start) although i was
> planning to make an init.d script for it given time..
>
> >
> > Since it is using odd paths i asume there is no redhat rpm?
>
> No, This is an RPM, but from Breach Security - the authors. I also
> installed it from source previously.

That explains the odd paths

>
> > >
> > > # ll /usr/local/bin/modsecurity-console
> > > lrwxrwxrwx. 1 root root 44 2010-04-04 11:23 /usr/local/bin/modsecurity-console -> /opt/modsecurity-console/modsecurity-console
> > >
> > > > >
> > > > > Note however that I am also experimenting with another Console app (also
> > > > > Java based, which does exactly the same thing in the same way) but in
> > > > > this case listens on port 8443.
> > > > >
> > > > > >
> > > > > > I am think about creating a file type transition from the generic log files type or httpd log files type to a mlogc log files type to be created by us.
> > > > > > This will benefit security as:
> > > > > >
> > > > > > 1. Hopefully mlogc_t will no longer need to manage files with type httpd_log_t.
> > > > > > 2. httpd_t (mod_security) will no longer need to create directories wuth type httpd_log_t and will no longer need to write to files with type httpd_log_t.
> > > > > >
> > > > > > We must try to find the best solution to the above securities issue so again: two questions:
> > > > > >
> > > > > > 1. does mod_security (mayve its configuration file) allow us to specify a location to store mod_security log files?
> > > > > > 2. if the answer to 1. is no, then can you tell me which directories in /var/log/httpd are used (owned) by mod_security for logging?
> > > > >
> > > > > The answer to 1 is yes as you can see above.
> > > > > >
> > > > > > > Raw Audit Messages :
> > > > > > >
> > > > > > > node=troodos.org.uk type=AVC msg=audit(1270679720.128:45085): avc: denied { name_connect } for pid=1869 comm="mlogc" dest=8888 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_ubject_rort_t:s0 tclass=tcp_socket
> > > > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270679720.128:45085): arch=40000003 syscall=102 success=no exit=-115 a0=3 a1=b62fa910 a2=4cb9a8 a3=0 items=0 ppid=937 pid=1869 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)
> > > > > >
> > > > > > The mlogc program tries to tcp network connect to port 8888, which currently is labeled with a generic port type.
> > > > > >
> > > > > > 1. Why is it connecting to the network?
> > > > > > 2. What is listening on tcp:8888 on the other side?
> > > > >
> > > > > That's the Console app as described above.
> > > > >
> > > > > >
> > > > > > We have to find some answers before we can start implementing a proper solution.
> > > > >
> > > > > [snip]
> > > > >
> > > > > > The above denials were what actually caused your issue in the first place. The only difference now is that instead of httpd_t, now mlogc_t need the access.
> > > > > >
> > > > > > Add the following to your mlogc.te file:
> > > > > >
> > > > > > pcscd_read_pub_files(mlogc_t)
> > > > > >
> > > > > > That should allow mlogc_t to read pcscd pid files.
> > > > >
> > > > > Done that - thanks..
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > And as I was copying the above, this one came in...
> > > > > > >
> > > > > > > Raw Audit Messages :
> > > > > > >
> > > > > > > node=troodos.org.uk type=AVC msg=audit(1270680011.472:45102): avc: denied { dac_override } for pid=952 comm="mlogc" capability=1 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=unconfined_u:system_r:mlogc_t:s0 tclass=capability
> > > > > > > node=troodos.org.uk type=SYSCALL msg=audit(1270680011.472:45102): arch=40000003 syscall=5 success=yes exit=6 a0=b76fd170 a1=82c1 a2=1b6 a3=856 items=0 ppid=937 pid=952 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)
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > The above means that root/mlogc is overriding traditional security. For example accessing a location not owned by root. We should figure out which location it is that mlogc tries to access that is not owned by root. Once we determine this, we can make the right security decision.
> > > > > >
> > > > > >
> > > > > > Now we are getting into the harder aspect of writing policy.
> > > > > > Writing a template for a new domain and just allowing access is not so hard.
> > > > > > What is harder is: making solid security decisions.
> > > > > >
> > > > > >
> > > > > > What is it doing
> > > > > > why is it doing it
> > > > > > who is doing it to who
> > > > > > Is this a threat
> > > > > > why is it a threat
> > > > > > how can we neutralize it?
> > > > > >
> > > > > > fun!
> > > > >
> > > > > For you maybe
> > > > >
> > > > > OK - I hope the above helps...
> > > > >
> > > > > By the way since my last message I have had another 71 AVcs - too many
> > > > > to post, and doubtless many duplicates, but here is what audit2allow has
> > > > > to say about them:
> > > > >
> > > > > # ausearch -m AVC -ts today | audit2allow -R
> > > > >
> > > > > require {
> > > > > type mlogc_t;
> > > > > type httpd_t;
> > > > > class capability { sys_nice dac_override };
> > > > > class process { setsched signal getsched };
> > > > > class sem { read write create unix_write destroy };
> > > > > }
> > > > >
> > > > > #============= httpd_t ==============
> > > > > allow httpd_t mlogc_trocess signal;
> > > >
> > > > Ignore this for now, we might add it later.
> > > >
> > > > >
> > > > > #============= mlogc_t ==============
> > > > > allow mlogc_t self:capability { sys_nice dac_override };
> > > >
> > > > Did you figure out which location not owned by root mlogc is trying to access?
> > > > For the moment lets ignore these.
> > > >
> > > > > allow mlogc_t selfrocess { setsched getsched };
> > > >
> > > > The above can be added to mlogc.te
> > > >
> > > > > allow mlogc_t self:sem { read write create unix_write destroy };
> > > >
> > > > Ignore for now
> > > >
> > > > > files_rw_etc_files(mlogc_t)
> >
> > The files_rw_etc_files(mlogc_t) is bad, if you added it, please remove it
>
> Nope. You didn't tell me to add it so I didn't. I only do what I'm
> told
>
> >
> > instead add the following to mlogc.te:
> >
> > type mlogc_etc_t;
> > files_config_file(mlogc_etc_t)
> > read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
> > files_search_etc(mlogc_t)
>
> Done.
>
> > And add to mlogc.fc:
> >
> > /etc/mlogc.conf -- gen_context(system_ubject_r:mlogc_etc_t, s0)
>
> Done.
>
>
> > > Having done all that (including moving mlogc back to /var/log/mlogc)
> > > these are the current AVCs (18 of them) since making the above changes:
> > >
> > > # ausearch -m AVC -ts recent | audit2allow -R
> > >
> > > require {
> > > type var_log_t;
> > > type httpd_log_t;
> > > type pcscd_t;
> > > type httpd_t;
> > > type mlogc_t;
> > > class capability dac_override;
> > > class unix_stream_socket connectto;
> > > class sem { read write unix_write };
> > > class file { write rename unlink };
> > > class dir create;
> > > }
> > >
> > > #============= httpd_t ==============
> > > allow httpd_t httpd_log_t:file write;
> > > allow httpd_t var_log_t:dir create;
> >
> > ignore above for now
> >
> > >
> > > #============= mlogc_t ==============
> > > allow mlogc_t httpd_log_t:file { rename unlink };
> > > allow mlogc_t pcscd_t:unix_stream_socket connectto;
> > > allow mlogc_t self:capability dac_override;
> > > allow mlogc_t self:sem { read write unix_write };
> > > corenet_tcp_connect_generic_port(mlogc_t)
> >
> > ignore above for now.
> >
> > > dev_read_urand(mlogc_t)
> >
> > add above to mlogc.te
>
> Done.
>
> > > files_list_tmp(mlogc_t)
> >
> > ignore above for now. need to figure out why its listing tmp, what is it hoping to list?
> >
> > > files_read_usr_symlinks(mlogc_t)
> >
> > not sure why it wants the above but its harmless, so can add it to mlogc.te for now
>
> Done.
>
> > > files_rw_etc_files(mlogc_t)
> >
> > This is a bug in audit2allow. We added proper rules above so ignore this.
> >
> > > miscfiles_read_certs(mlogc_t)
> > > pcscd_stream_connect(mlogc_t)
> >
> > The above can be added to mlogc.te
>
> Done.
>
>
> OK - Let's see what that brings...
>
> Oops:
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted mlogc module
> /usr/bin/checkmodule: loading policy configuration from tmp/mlogc.tmp
> mlogc.te":16:ERROR 'unknown type mlogc_etc_t' at token ';' on line 3828:
> typeattribute mlogc_etc_t etcfile;
> #line 16
> /usr/bin/checkmodule: error(s) encountered while parsing configuration
> make: *** [tmp/mlogc.mod] Error 1
>

no, you forgot to declare "type mlogc_etc_t;" in mlogc.te

> Is this the problem?
> read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
> 2 x mlogc_etc_t ? Should that be something else or just 1 x ?
>
> Here is the current mlogc.te
>
> # cat mlogc.te
> policy_module(mlogc, 1.0.3)
>
> type mlogc_t;
> type mlogc_exec_t;
> type mlogc_var_log_t;
>
> logging_log_file(mlogc_var_log_t);
> logging_log_filetrans(mlogc_t, mlogc_var_log_t, { dir file })
> application_domain(mlogc_t, mlogc_exec_t);
> role system_r types mlogc_t;
> permissive mlogc_t;
> manage_dirs_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> manage_files_pattern(mlogc_t, mlogc_var_log_t, mlogc_var_log_t)
> read_files_pattern(mlogc_t, mlogc_etc_t, mlogc_etc_t)
> files_search_etc(mlogc_t)
> files_config_file(mlogc_etc_t)
> files_read_usr_symlinks(mlogc_t)
> pcscd_read_pub_files(mlogc_t);
> pcscd_stream_connect(mlogc_t)
> miscfiles_read_localization(mlogc_t)
> miscfiles_read_certs(mlogc_t)
> dev_read_urand(mlogc_t)
> #apache_manage_log(mlogc_t);
>
> allow mlogc_t self:tcp_socket create_socket_perms;
> allow mlogc_t self:udp_socket create_socket_perms;
> allow mlogc_t self:netlink_route_socket create_netlink_socket_perms;
> allow mlogc_t selfrocess { setsched getsched };
>
>
>
>
>



> --
> 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:32 PM.

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