Hello all,
Back in April Dominick Grift kindly helped me to create a new policy module for mlogc on my Fedora11 installation.
(The original correspondence can be seen here: http://lists.fedoraproject.org/pipermail/selinux/2010-April/012353.html)
In the last couple of days I have upgraded to F13 and, despite copying and rebuilding the relevant policy modules, I am now getting another raft of AVCs relating to mlogc.
To Summarise: =============
ModSecurity Log Collector (mlogc) is used to send ModSecurity audit log data to a console. It is installed as part of the Fedora rpm mod_security-2.5.12-1.fc13.i686 which I installed as part of the upgrade. The Actual Modsecurity Console (which receives the data) was installed from source using the same tarball as was used on my F11 install.
With Dominick's help, these are the modules I created on the F11 box:
===========8<=======================================================
# cat mymlogc.te policy_module(mymlogc, 1.0.10)
type mlogc_t; type mlogc_exec_t; type mlogc_var_log_t; type mlogc_etc_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) files_read_etc_files(mlogc_t) files_list_tmp(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) userdom_use_user_terminals(mlogc_t) #apache_manage_log(mlogc_t); kernel_read_system_state(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 self:process { setsched getsched }; allow mlogc_t self:capability { sys_nice dac_override }; allow mlogc_t self:sem create_sem_perms;
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) ===========8<=======================================================
===========8<=======================================================
# cat myapche.te policy_module(myapache, 1.0.2) gen_require(` type httpd_t; ') mlogc_domtrans(httpd_t) mlogc_manage_log(httpd_t) mlogc_signal(httpd_t)
===========8<=======================================================
And these are the new denials. Some worrying ones such as requiring access to key files...
There were 12 AVCs relating to a single incident, but I have removed ones I think are duplicates:
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.635:29370): avc: denied { write } for pid=3512 comm="mlogc" name="cert9.db" dev=sda6 ino=91782 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281734421.635:29370): arch=40000003 syscall=5 success=no exit=-13 a0=b5926308 a1=8042 a2=1a4 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29371): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=1549 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29371): arch=40000003 syscall=33 success=no exit=-13 a0=1e6774 a1=7 a2=1fca64 a3=2 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29373): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=310 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29373): arch=40000003 syscall=33 success=no exit=-13 a0=1e6778 a1=7 a2=1fca64 a3=4 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29374): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29374): arch=40000003 syscall=33 success=no exit=-13 a0=1e4d73 a1=7 a2=1fca64 a3=5 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.852:29376): avc: denied { write } for pid=3512 comm="mlogc" name="key4.db" dev=sda6 ino=19637 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281734421.852:29376): arch=40000003 syscall=5 success=no exit=-13 a0=b5933cf8 a1=8042 a2=1a4 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29380): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29380): arch=40000003 syscall=33 success=no exit=-13 a0=1e4d73 a1=7 a2=1fca64 a3=5 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
1. I would go here: https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
2. You have a partition mounted that is not labelled properly. It is: /dev/sda6. Where is that mounted?
3. Looks like mlogc wants to maintain objects in /tmp. However your logs do not display what kind of objects ( e.g. it is incomplete )
You may have removed log entries that were no duplicates.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Hi Dominick!
Thanks for coming to my aid once more.
On Sat, 2010-08-14 at 10:45 +0200, Dominick Grift wrote:
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
I am already subscribed to that list so I'll post a message now...
- You have a partition mounted that is not labelled properly. It is:
/dev/sda6. Where is that mounted?
Hmmm... That's /
!!!
Essentially I have 3 partitions (more actually, but 3 relevant to this) sda5, sda6 and sda8. sda8 is /home and each time I upgrade Fedora I use the previous partition - so sda6 is where F13 resides and sda5 still has F11 (mounted on /mnt/f11 - so I can refer back to previous configs etc.)
When I upgrade to F14 I will install it in sda5 and keep F13 in sda6. I have done this since Redhat6 !
- Looks like mlogc wants to maintain objects in /tmp. However your logs
do not display what kind of objects ( e.g. it is incomplete )
Sorry I don't understand what you mean...
You may have removed log entries that were no duplicates.
OK here are all 12...
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.635:29370): avc: denied { write } for pid=3512 comm="mlogc" name="cert9.db" dev=sda6 ino=91782 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281734421.635:29370): arch=40000003 syscall=5 success=no exit=-13 a0=b5926308 a1=8042 a2=1a4 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29371): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=1549 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29371): arch=40000003 syscall=33 success=no exit=-13 a0=1e6774 a1=7 a2=1fca64 a3=2 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29372): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=1549 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29372): arch=40000003 syscall=33 success=no exit=-13 a0=1e677d a1=7 a2=1fca64 a3=3 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29373): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=310 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29373): arch=40000003 syscall=33 success=no exit=-13 a0=1e6778 a1=7 a2=1fca64 a3=4 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.847:29374): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.847:29374): arch=40000003 syscall=33 success=no exit=-13 a0=1e4d73 a1=7 a2=1fca64 a3=5 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.852:29375): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.852:29375): arch=40000003 syscall=5 success=no exit=-13 a0=b642097b a1=8042 a2=180 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.852:29376): avc: denied { write } for pid=3512 comm="mlogc" name="key4.db" dev=sda6 ino=19637 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281734421.852:29376): arch=40000003 syscall=5 success=no exit=-13 a0=b5933cf8 a1=8042 a2=1a4 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29377): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=1549 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29377): arch=40000003 syscall=33 success=no exit=-13 a0=1e6774 a1=7 a2=1fca64 a3=2 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29378): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=1549 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29378): arch=40000003 syscall=33 success=no exit=-13 a0=1e677d a1=7 a2=1fca64 a3=3 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29379): avc: denied { write } for pid=3512 comm="mlogc" name="tmp" dev=sda6 ino=310 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29379): arch=40000003 syscall=33 success=no exit=-13 a0=1e6778 a1=7 a2=1fca64 a3=4 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29380): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29380): arch=40000003 syscall=33 success=no exit=-13 a0=1e4d73 a1=7 a2=1fca64 a3=5 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
Raw Audit Messages :
node=troodos type=AVC msg=audit(1281734421.861:29381): avc: denied { write } for pid=3512 comm="mlogc" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=troodos type=SYSCALL msg=audit(1281734421.861:29381): arch=40000003 syscall=5 success=no exit=-13 a0=b642097b a1=8042 a2=180 a3=0 items=0 ppid=1506 pid=3512 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=system_u:system_r:mlogc_t:s0 key=(null)
On 08/14/2010 11:35 AM, Arthur Dent wrote:
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
I am already subscribed to that list so I'll post a message now...
- You have a partition mounted that is not labelled properly. It is:
/dev/sda6. Where is that mounted?
Hmmm... That's /
Ok it looks like it might want to dump core then:
Add the following to your mymlogc.te to allow mlogc_t to dump core (manage files in /)
files_manage_root_files(mlogc_t)
- Looks like mlogc wants to maintain objects in /tmp. However your logs
do not display what kind of objects ( e.g. it is incomplete )
Sorry I don't understand what you mean...
You may have removed log entries that were no duplicates.
OK here are all 12...
Ok it is still not displaying, That is because it is denied access. So i will for now assume it wants to maintain a file in /tmp:
Add the following to your mymlogc.te file for now:
type mlogc_tmp_t; files_tmp_file(mlogc_tmp_t)
manage_files_pattern(mlogc_t, mlogc_tmp_t, mlogc_tmp_t) files_tmp_filetrans(mlogc_t, mlogc_tmp_t, file)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Sat, 2010-08-14 at 10:45 +0200, Dominick Grift wrote:
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
OK - Sorry it's taken a while to get back to this - but I had the discussion over on the mod-sec list, had to set up a strace and send the strace log.
This is what Brian Rectanus had to say having analysed the strace log:
====================8<=================================================
Looking at the strace logs, it first tries to open those files read/write, but cannot, so it resorts to read only access. I do not see any calls to write to those files, though:
14612 open("/etc/pki/nssdb/key4.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/key4.db", O_RDONLY|O_LARGEFILE) = 11
14612 open("/etc/pki/nssdb/cert9.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/cert9.db", O_RDONLY|O_LARGEFILE) = 8
I imagine that those attempts at opening read/write are what is triggering selinux. This is the curl library access these files for certificate verification (via mozilla's NSS library). They are sqlite DBs. I am not sure why it is trying to access them read/write, though. It looks like NSS support was added to curl with version 7.19.7. If it is a problem (and it may be), then you will probably have to take it up with curl folks. However, they will probably tell you it is a libnss issue :)
Sorry I cannot help more.
-B
====================8<=================================================
Well - Where does that leave me?
Mark
On 08/31/2010 08:33 PM, Arthur Dent wrote:
On Sat, 2010-08-14 at 10:45 +0200, Dominick Grift wrote:
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
OK - Sorry it's taken a while to get back to this - but I had the discussion over on the mod-sec list, had to set up a strace and send the strace log.
This is what Brian Rectanus had to say having analysed the strace log:
====================8<=================================================
Looking at the strace logs, it first tries to open those files read/write, but cannot, so it resorts to read only access. I do not see any calls to write to those files, though:
14612 open("/etc/pki/nssdb/key4.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/key4.db", O_RDONLY|O_LARGEFILE) = 11
14612 open("/etc/pki/nssdb/cert9.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/cert9.db", O_RDONLY|O_LARGEFILE) = 8
I imagine that those attempts at opening read/write are what is triggering selinux. This is the curl library access these files for certificate verification (via mozilla's NSS library). They are sqlite DBs. I am not sure why it is trying to access them read/write, though. It looks like NSS support was added to curl with version 7.19.7. If it is a problem (and it may be), then you will probably have to take it up with curl folks. However, they will probably tell you it is a libnss issue :)
Sorry I cannot help more.
-B
====================8<=================================================
Well - Where does that leave me?
Mark
I guess you will have to decide for yourself whether you want to permit mlogc to read and write your system certificate files.
Try to reproduce the issue in permissive mode and enclose the AVC denials so that we can extend the mlogc module.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Tue, 2010-08-31 at 20:39 +0200, Dominick Grift wrote:
On 08/31/2010 08:33 PM, Arthur Dent wrote:
On Sat, 2010-08-14 at 10:45 +0200, Dominick Grift wrote:
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
OK - Sorry it's taken a while to get back to this - but I had the discussion over on the mod-sec list, had to set up a strace and send the strace log.
This is what Brian Rectanus had to say having analysed the strace log:
====================8<=================================================
Looking at the strace logs, it first tries to open those files read/write, but cannot, so it resorts to read only access. I do not see any calls to write to those files, though:
14612 open("/etc/pki/nssdb/key4.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/key4.db", O_RDONLY|O_LARGEFILE) = 11
14612 open("/etc/pki/nssdb/cert9.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/cert9.db", O_RDONLY|O_LARGEFILE) = 8
I imagine that those attempts at opening read/write are what is triggering selinux. This is the curl library access these files for certificate verification (via mozilla's NSS library). They are sqlite DBs. I am not sure why it is trying to access them read/write, though. It looks like NSS support was added to curl with version 7.19.7. If it is a problem (and it may be), then you will probably have to take it up with curl folks. However, they will probably tell you it is a libnss issue :)
Sorry I cannot help more.
-B
====================8<=================================================
Well - Where does that leave me?
Mark
I guess you will have to decide for yourself whether you want to permit mlogc to read and write your system certificate files.
Try to reproduce the issue in permissive mode and enclose the AVC denials so that we can extend the mlogc module.
Reproducing it in permissive mode will take a little effort (I either have to wait for an event - not too frequent at the moment - or try to re-inject a previous event).
In the meantime, here are the two most recent whilst in enforcing mode:
Raw Audit Messages :
node=troodos type=AVC msg=audit(1282523196.610:41408): avc: denied { write } for pid=16293 comm="mlogc" name="cert9.db" dev=sda6 ino=86078 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1282523196.610:41408): arch=40000003 syscall=5 success=no exit=-13 a0=b5726328 a1=8042 a2=1a4 a3=0 items=0 ppid=14657 pid=16293 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 type=AVC msg=audit(1282523196.662:41409): avc: denied { write } for pid=16293 comm="mlogc" name="key4.db" dev=sda6 ino=86176 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1282523196.662:41409): arch=40000003 syscall=5 success=no exit=-13 a0=b5736680 a1=8042 a2=1a4 a3=0 items=0 ppid=14657 pid=16293 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)
Thanks
Mark
On 08/31/2010 09:06 PM, Arthur Dent wrote:
On Tue, 2010-08-31 at 20:39 +0200, Dominick Grift wrote:
On 08/31/2010 08:33 PM, Arthur Dent wrote:
On Sat, 2010-08-14 at 10:45 +0200, Dominick Grift wrote:
On 08/14/2010 10:06 AM, Arthur Dent wrote:
And this is what audit2allow makes of them...
require { type mlogc_t; }
#============= mlogc_t ============== files_delete_root_dir_entry(mlogc_t) files_delete_tmp_dir_entry(mlogc_t) miscfiles_manage_cert_files(mlogc_t)
Should I add these to the above policy, or is there some other way?
Thanks in advance for any help or suggestions...
Mark
There are some issues:
- I would go here:
https://lists.sourceforge.net/lists/listinfo/mod-security-users and ask if it is normal that mlogc writes to certificate databases. Its trying to write to files like: cert9.db, key4.db.
OK - Sorry it's taken a while to get back to this - but I had the discussion over on the mod-sec list, had to set up a strace and send the strace log.
This is what Brian Rectanus had to say having analysed the strace log:
====================8<=================================================
Looking at the strace logs, it first tries to open those files read/write, but cannot, so it resorts to read only access. I do not see any calls to write to those files, though:
14612 open("/etc/pki/nssdb/key4.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/key4.db", O_RDONLY|O_LARGEFILE) = 11
14612 open("/etc/pki/nssdb/cert9.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) 14612 open("/etc/pki/nssdb/cert9.db", O_RDONLY|O_LARGEFILE) = 8
I imagine that those attempts at opening read/write are what is triggering selinux. This is the curl library access these files for certificate verification (via mozilla's NSS library). They are sqlite DBs. I am not sure why it is trying to access them read/write, though. It looks like NSS support was added to curl with version 7.19.7. If it is a problem (and it may be), then you will probably have to take it up with curl folks. However, they will probably tell you it is a libnss issue :)
Sorry I cannot help more.
-B
====================8<=================================================
Well - Where does that leave me?
Mark
I guess you will have to decide for yourself whether you want to permit mlogc to read and write your system certificate files.
Try to reproduce the issue in permissive mode and enclose the AVC denials so that we can extend the mlogc module.
Reproducing it in permissive mode will take a little effort (I either have to wait for an event - not too frequent at the moment - or try to re-inject a previous event).
In the meantime, here are the two most recent whilst in enforcing mode:
Raw Audit Messages :
node=troodos type=AVC msg=audit(1282523196.610:41408): avc: denied { write } for pid=16293 comm="mlogc" name="cert9.db" dev=sda6 ino=86078 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1282523196.610:41408): arch=40000003 syscall=5 success=no exit=-13 a0=b5726328 a1=8042 a2=1a4 a3=0 items=0 ppid=14657 pid=16293 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 type=AVC msg=audit(1282523196.662:41409): avc: denied { write } for pid=16293 comm="mlogc" name="key4.db" dev=sda6 ino=86176 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1282523196.662:41409): arch=40000003 syscall=5 success=no exit=-13 a0=b5736680 a1=8042 a2=1a4 a3=0 items=0 ppid=14657 pid=16293 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)
Thanks
Mark
adding the following to your mlogc.te miscfiles_manage_cert_files(mlogc_t) Would allow this
Then build, install mlogc.pp
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Arthur Dent -
Dominick Grift