Thread: [mod-security-users] mlogc and selinux
Brought to you by:
victorhora,
zimmerletw
From: Arthur D. <mis...@bl...> - 2010-08-14 10:21:25
|
Hello all, I have been running - very successfully - ModSec for some years and, since about April, the Modsecurity Console (with mlogc) on my Fedora11 machine. I needed to create a Selinux policy for it, but with the help of the selinux mailing list I did so and all was well.. Now I have upgraded to Fedora13. Re-installing modsecurity (from yum) works OK, but I now have some new selinux denials. In particular I am worried about a couple of denials that relate to key certificates. The selinux denials show that mlogc is trying to write to files like: cert9.db, key4.db. Is this normal? If so, why did I not get it under F11? Any advice or suggestions gratefully received... Thanks Mark |
From: Brian R. <bre...@gm...> - 2010-08-14 19:01:16
|
Mlogc should not be writing to any such files. Perhaps it just opened them as read/write? Even so, this would have been the libcurl lib and not mlogc directly. Perhaps the difference from F11 to F13 is the libcurl version? If you can get a trace of the system calls from mlogc that would be handy. -B On Aug 14, 2010 3:27 AM, "Arthur Dent" <mis...@bl...> wrote: Hello all, I have been running - very successfully - ModSec for some years and, since about April, the Modsecurity Console (with mlogc) on my Fedora11 machine. I needed to create a Selinux policy for it, but with the help of the selinux mailing list I did so and all was well.. Now I have upgraded to Fedora13. Re-installing modsecurity (from yum) works OK, but I now have some new selinux denials. In particular I am worried about a couple of denials that relate to key certificates. The selinux denials show that mlogc is trying to write to files like: cert9.db, key4.db. Is this normal? If so, why did I not get it under F11? Any advice or suggestions gratefully received... Thanks Mark ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Appliances, Rule Sets and Support: http://www.modsecurity.org/breach/index.html |
From: Arthur D. <mis...@bl...> - 2010-08-14 19:31:14
|
On Sat, 2010-08-14 at 12:01 -0700, Brian Rectanus wrote: > Mlogc should not be writing to any such files. Perhaps it just opened > them as read/write? Even so, this would have been the libcurl lib and > not mlogc directly. Perhaps the difference from F11 to F13 is the > libcurl version? > > If you can get a trace of the system calls from mlogc that would be > handy. > > -B OK - I can reproduce the selinux AVCs at will by re-injecting a previous attack using Christian Bockerman's AuditViewer tool. However, I have never used trace before and I'm not sure how to use it specifically to get the information relating to mlogc. If you can give me an idiot's guide (or point me to a useful tutorial - the ones I have just looked at are too general) to get the info you need, then I will gladly do so. In case they are of interest, here are the two selinux denials I just triggered by re-injecting the earlier attack: Raw Audit Messages : node=troodos type=AVC msg=audit(1281813288.228:31252): avc: denied { write } for pid=6436 comm="mlogc" name="cert9.db" dev=sda6 ino=91782 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281813288.228:31252): arch=40000003 syscall=5 success=no exit=-13 a0=b5826340 a1=8042 a2=1a4 a3=0 items=0 ppid=5943 pid=6436 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(1281813288.241:31253): avc: denied { write } for pid=6436 comm="mlogc" name="key4.db" dev=sda6 ino=19637 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file node=troodos type=SYSCALL msg=audit(1281813288.241:31253): arch=40000003 syscall=5 success=no exit=-13 a0=b5836698 a1=8042 a2=1a4 a3=0 items=0 ppid=5943 pid=6436 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 Aug 14, 2010 3:27 AM, "Arthur Dent" <mis...@bl...> > > wrote: > > > > Hello all, > > > > I have been running - very successfully - ModSec for some years and, > > since about April, the Modsecurity Console (with mlogc) on my > > Fedora11 > > machine. I needed to create a Selinux policy for it, but with the > > help > > of the selinux mailing list I did so and all was well.. > > > > Now I have upgraded to Fedora13. Re-installing modsecurity (from > > yum) > > works OK, but I now have some new selinux denials. In particular I > > am > > worried about a couple of denials that relate to key certificates. > > > > The selinux denials show that mlogc is trying > > to write to files like: cert9.db, key4.db. Is this normal? > > If so, why did I not get it under F11? > > > > Any advice or suggestions gratefully received... > > > > Thanks > > > > Mark |
From: Brian R. <bre...@gm...> - 2010-08-15 17:52:24
|
Probably strace is the easiest for you. Here is a short intro to using strace... http://www.hokstad.com/5-simple-ways-to-troubleshoot-using-strace.html Probably something along these lines will work (untest script, but should work): 1) create a wrapper script to launch mlogc in trace mode: #!/bin/sh REAL_MLOGC=/usr/local/bin/mlogc LOGFILE=/tmp/mlogc-strace.log exec strace -f -e trace=open,close,read,write -s 8192 -o $LOGFILE $REAL_MLOGC "$@" NOTE: You need the -f to get at all the different threads, but you may need to leave off the -e trace=... option if this filter is not getting you the data you need, but it will make the log huge. 2) Setup apache to use this shell script wrapper instead of the real mlogc binary. This will show you all the files that are opened/closed and read/written to in the LOGFILE -B On Sat, Aug 14, 2010 at 12:30 PM, Arthur Dent <mis...@bl...> wrote: > On Sat, 2010-08-14 at 12:01 -0700, Brian Rectanus wrote: >> Mlogc should not be writing to any such files. Perhaps it just opened >> them as read/write? Even so, this would have been the libcurl lib and >> not mlogc directly. Perhaps the difference from F11 to F13 is the >> libcurl version? >> >> If you can get a trace of the system calls from mlogc that would be >> handy. >> >> -B > > OK - I can reproduce the selinux AVCs at will by re-injecting a previous > attack using Christian Bockerman's AuditViewer tool. However, I have > never used trace before and I'm not sure how to use it specifically to > get the information relating to mlogc. > > If you can give me an idiot's guide (or point me to a useful tutorial - > the ones I have just looked at are too general) to get the info you > need, then I will gladly do so. > > In case they are of interest, here are the two selinux denials I just > triggered by re-injecting the earlier attack: > > Raw Audit Messages : > > node=troodos type=AVC msg=audit(1281813288.228:31252): avc: denied { write } for pid=6436 comm="mlogc" name="cert9.db" dev=sda6 ino=91782 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > node=troodos type=SYSCALL msg=audit(1281813288.228:31252): arch=40000003 syscall=5 success=no exit=-13 a0=b5826340 a1=8042 a2=1a4 a3=0 items=0 ppid=5943 pid=6436 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(1281813288.241:31253): avc: denied { write } for pid=6436 comm="mlogc" name="key4.db" dev=sda6 ino=19637 scontext=unconfined_u:system_r:mlogc_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > node=troodos type=SYSCALL msg=audit(1281813288.241:31253): arch=40000003 syscall=5 success=no exit=-13 a0=b5836698 a1=8042 a2=1a4 a3=0 items=0 ppid=5943 pid=6436 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 Aug 14, 2010 3:27 AM, "Arthur Dent" <mis...@bl...> >> > wrote: >> > >> > Hello all, >> > >> > I have been running - very successfully - ModSec for some years and, >> > since about April, the Modsecurity Console (with mlogc) on my >> > Fedora11 >> > machine. I needed to create a Selinux policy for it, but with the >> > help >> > of the selinux mailing list I did so and all was well.. >> > >> > Now I have upgraded to Fedora13. Re-installing modsecurity (from >> > yum) >> > works OK, but I now have some new selinux denials. In particular I >> > am >> > worried about a couple of denials that relate to key certificates. >> > >> > The selinux denials show that mlogc is trying >> > to write to files like: cert9.db, key4.db. Is this normal? >> > If so, why did I not get it under F11? >> > >> > Any advice or suggestions gratefully received... >> > >> > Thanks >> > >> > Mark > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Appliances, Rule Sets and Support: > http://www.modsecurity.org/breach/index.html > |
From: Arthur D. <mis...@bl...> - 2010-08-15 18:30:58
|
On Sun, 2010-08-15 at 10:52 -0700, Brian Rectanus wrote: > Probably strace is the easiest for you. Here is a short intro to > using strace... > > http://www.hokstad.com/5-simple-ways-to-troubleshoot-using-strace.html > > Probably something along these lines will work (untest script, but should work): > > 1) create a wrapper script to launch mlogc in trace mode: > > #!/bin/sh > REAL_MLOGC=/usr/local/bin/mlogc > LOGFILE=/tmp/mlogc-strace.log > exec strace -f -e trace=open,close,read,write -s 8192 -o $LOGFILE > $REAL_MLOGC "$@" > > NOTE: You need the -f to get at all the different threads, but you may > need to leave off the -e trace=... option if this filter is not > getting you the data you need, but it will make the log huge. > > 2) Setup apache to use this shell script wrapper instead of the real > mlogc binary. > > This will show you all the files that are opened/closed and > read/written to in the LOGFILE > > -B > OK Brian - Thanks for this... really helpful. Unfortunately there appears to be a syntax error in the strace command, but for the life of me I cannot work out what it is. Restarting apache failed so I investigated by running the script directly. It gives this output: # ./mlogc-strace.sh usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file] [-p pid] ... [-s strsize] [-u username] [-E var=val] ... [command [arg ...]] or: strace -c -D [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ... [command [arg ...]] -c -- count time, calls, and errors for each syscall and report summary -f -- follow forks, -ff -- with output into separate files -F -- attempt to follow vforks, -h -- print help message -i -- print instruction pointer at time of syscall -q -- suppress messages about attaching, detaching, etc. -r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs -T -- print time spent in each syscall, -V -- print version -v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args -x -- print non-ascii strings in hex, -xx -- print all strings in hex -a column -- alignment COLUMN for printing syscall results (default 40) -e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]... options: trace, abbrev, verbose, raw, signal, read, or write -o file -- send trace output to FILE instead of stderr -O overhead -- set overhead for tracing syscalls to OVERHEAD usecs -p pid -- trace process with process id PID, may be repeated -D -- run tracer process as a detached grandchild, not as parent -s strsize -- limit length of print strings to STRSIZE chars (default 32) -S sortby -- sort syscall counts by: time, calls, name, nothing (default time) -u username -- run command as username handling setuid and/or setgid -E var=val -- put var=val in the environment for command -E var -- remove var from the environment for command Now I have carefully read through your call to strace and it seems to correspond to the syntax as listed above. I have tried with "-e trace=all" - no joy and I have tried altering the sequence of switches (to -f -e -o -s) in case that made a difference. It didn't... Sorry to be so lame, but this is not my area of expertise (not that anything much else is...) Thanks for your help so far. Any ideas? Mark |
From: Brian R. <bre...@gm...> - 2010-08-15 19:25:58
|
Syntax looks correct. Try adding a "set -x" on a line just after the #!/bin/sh line which will show all the commands being executed with vars substituted and may show the issue. -B On Aug 15, 2010 11:34 AM, "Arthur Dent" <mis...@bl...> wrote: On Sun, 2010-08-15 at 10:52 -0700, Brian Rectanus wrote: > Probably strace is the easiest for you. ... OK Brian - Thanks for this... really helpful. Unfortunately there appears to be a syntax error in the strace command, but for the life of me I cannot work out what it is. Restarting apache failed so I investigated by running the script directly. It gives this output: # ./mlogc-strace.sh usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file] [-p pid] ... [-s strsize] [-u username] [-E var=val] ... [command [arg ...]] or: strace -c -D [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ... [command [arg ...]] -c -- count time, calls, and errors for each syscall and report summary -f -- follow forks, -ff -- with output into separate files -F -- attempt to follow vforks, -h -- print help message -i -- print instruction pointer at time of syscall -q -- suppress messages about attaching, detaching, etc. -r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs -T -- print time spent in each syscall, -V -- print version -v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args -x -- print non-ascii strings in hex, -xx -- print all strings in hex -a column -- alignment COLUMN for printing syscall results (default 40) -e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]... options: trace, abbrev, verbose, raw, signal, read, or write -o file -- send trace output to FILE instead of stderr -O overhead -- set overhead for tracing syscalls to OVERHEAD usecs -p pid -- trace process with process id PID, may be repeated -D -- run tracer process as a detached grandchild, not as parent -s strsize -- limit length of print strings to STRSIZE chars (default 32) -S sortby -- sort syscall counts by: time, calls, name, nothing (default time) -u username -- run command as username handling setuid and/or setgid -E var=val -- put var=val in the environment for command -E var -- remove var from the environment for command Now I have carefully read through your call to strace and it seems to correspond to the syntax as listed above. I have tried with "-e trace=all" - no joy and I have tried altering the sequence of switches (to -f -e -o -s) in case that made a difference. It didn't... Sorry to be so lame, but this is not my area of expertise (not that anything much else is...) Thanks for your help so far. Any ideas? Mark ------------------------------------------------------------------------------ This SF.n... |
From: Arthur D. <mis...@bl...> - 2010-08-15 19:48:15
|
Oops... Apologies. Accidentally replied to Brian rather than the list. Here goes again. Sorry... On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > Syntax looks correct. Try adding a "set -x" on a line just after the > #!/bin/sh line which will show all the commands being executed with > vars substituted and may show the issue. Sorry - that didn't help... # ./mlogc-strace.sh + REAL_MLOGC=/usr/bin/mlogc + LOGFILE=/tmp/mlogc-strace.log + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file] [-p pid] ... [-s strsize] [-u username] [-E var=val] ... [command [arg ...]] or: strace -c -D [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ... [command [arg ...]] -c -- count time, calls, and errors for each syscall and report summary -f -- follow forks, -ff -- with output into separate files -F -- attempt to follow vforks, -h -- print help message -i -- print instruction pointer at time of syscall -q -- suppress messages about attaching, detaching, etc. -r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs -T -- print time spent in each syscall, -V -- print version -v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args -x -- print non-ascii strings in hex, -xx -- print all strings in hex -a column -- alignment COLUMN for printing syscall results (default 40) -e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]... options: trace, abbrev, verbose, raw, signal, read, or write -o file -- send trace output to FILE instead of stderr -O overhead -- set overhead for tracing syscalls to OVERHEAD usecs -p pid -- trace process with process id PID, may be repeated -D -- run tracer process as a detached grandchild, not as parent -s strsize -- limit length of print strings to STRSIZE chars (default 32) -S sortby -- sort syscall counts by: time, calls, name, nothing (default time) -u username -- run command as username handling setuid and/or setgid -E var=val -- put var=val in the environment for command -E var -- remove var from the environment for command |
From: Arthur D. <mis...@bl...> - 2010-08-15 20:03:03
|
On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > Syntax looks correct. Try adding a "set -x" on a line just after the > #!/bin/sh line which will show all the commands being executed with > vars substituted and may show the issue. > > -B Sorry - that didn't help... # ./mlogc-strace.sh + REAL_MLOGC=/usr/bin/mlogc + LOGFILE=/tmp/mlogc-strace.log + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file] [-p pid] ... [-s strsize] [-u username] [-E var=val] ... [command [arg ...]] or: strace -c -D [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ... [command [arg ...]] -c -- count time, calls, and errors for each syscall and report summary -f -- follow forks, -ff -- with output into separate files -F -- attempt to follow vforks, -h -- print help message -i -- print instruction pointer at time of syscall -q -- suppress messages about attaching, detaching, etc. -r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs -T -- print time spent in each syscall, -V -- print version -v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args -x -- print non-ascii strings in hex, -xx -- print all strings in hex -a column -- alignment COLUMN for printing syscall results (default 40) -e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]... options: trace, abbrev, verbose, raw, signal, read, or write -o file -- send trace output to FILE instead of stderr -O overhead -- set overhead for tracing syscalls to OVERHEAD usecs -p pid -- trace process with process id PID, may be repeated -D -- run tracer process as a detached grandchild, not as parent -s strsize -- limit length of print strings to STRSIZE chars (default 32) -S sortby -- sort syscall counts by: time, calls, name, nothing (default time) -u username -- run command as username handling setuid and/or setgid -E var=val -- put var=val in the environment for command -E var -- remove var from the environment for command |
From: Brian R. <bre...@gm...> - 2010-08-16 07:33:55
|
On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent <mis...@bl...> wrote: > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: >> Syntax looks correct. Try adding a "set -x" on a line just after the >> #!/bin/sh line which will show all the commands being executed with >> vars substituted and may show the issue. >> >> -B > > Sorry - that didn't help... Ahh, but it did :) > > # ./mlogc-strace.sh > + REAL_MLOGC=/usr/bin/mlogc > + LOGFILE=/tmp/mlogc-strace.log > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log It shows that the email wrapped my script and put the $REAL_MLOGC "$@" On a line by itself (ie not executed after the exec), when it was supposed to be at the end of the strace line. Try this version with the line continuations :) #!/bin/sh REAL_MLOGC=/usr/local/bin/mlogc LOGFILE=/tmp/mlogc-strace.log exec strace \ -f -e trace=open,close,read,write \ -s 8192 -o $LOGFILE \ $REAL_MLOGC "$@" -B |
From: Arthur D. <mis...@bl...> - 2010-08-16 09:46:28
|
On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > <mis...@bl...> wrote: > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > >> Syntax looks correct. Try adding a "set -x" on a line just after the > >> #!/bin/sh line which will show all the commands being executed with > >> vars substituted and may show the issue. > >> > >> -B > > > > Sorry - that didn't help... > > Ahh, but it did :) > > > > > # ./mlogc-strace.sh > > + REAL_MLOGC=/usr/bin/mlogc > > + LOGFILE=/tmp/mlogc-strace.log > > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log > > It shows that the email wrapped my script and put the > > $REAL_MLOGC "$@" > > On a line by itself (ie not executed after the exec), when it was > supposed to be at the end of the strace line. Try this version with > the line continuations :) > > #!/bin/sh > REAL_MLOGC=/usr/local/bin/mlogc > LOGFILE=/tmp/mlogc-strace.log > exec strace \ > -f -e trace=open,close,read,write \ > -s 8192 -o $LOGFILE \ > $REAL_MLOGC "$@" > > -B OK - Brilliant! Sorry that was my bad. I misunderstood what that line was doing. Now. I'm afraid I'm just about to leave for the airport, so I won't have a chance to try this until I'm back next weekend. I could try to ssh into my server from an internet cafe somewhere, but there is a very real possibility that my wife will divorce me. So... I'll report back next week... Cheers. Mark |
From: Arthur D. <mis...@bl...> - 2010-08-21 19:54:51
|
On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: > On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > > <mis...@bl...> wrote: > > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > > >> Syntax looks correct. Try adding a "set -x" on a line just after the > > >> #!/bin/sh line which will show all the commands being executed with > > >> vars substituted and may show the issue. > > >> > > >> -B > > > > > > Sorry - that didn't help... > > > > Ahh, but it did :) > > > > > > > > # ./mlogc-strace.sh > > > + REAL_MLOGC=/usr/bin/mlogc > > > + LOGFILE=/tmp/mlogc-strace.log > > > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log > > > > It shows that the email wrapped my script and put the > > > > $REAL_MLOGC "$@" > > > > On a line by itself (ie not executed after the exec), when it was > > supposed to be at the end of the strace line. Try this version with > > the line continuations :) > > > > #!/bin/sh > > REAL_MLOGC=/usr/local/bin/mlogc > > LOGFILE=/tmp/mlogc-strace.log > > exec strace \ > > -f -e trace=open,close,read,write \ > > -s 8192 -o $LOGFILE \ > > $REAL_MLOGC "$@" > > > > -B > > OK - Brilliant! > > Sorry that was my bad. I misunderstood what that line was doing. > > Now. I'm afraid I'm just about to leave for the airport, so I won't have > a chance to try this until I'm back next weekend. I could try to ssh > into my server from an internet cafe somewhere, but there is a very real > possibility that my wife will divorce me. So... I'll report back next > week... Right... Back from my hols... OK - So the the line continuations this is what I get... ====================8<===================================== # ./mlogc-strace.sh + REAL_MLOGC=/usr/bin/mlogc + LOGFILE=/tmp/mlogc-strace.log + exec /usr/bin/strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log /usr/bin/mlogc ModSecurity Log Collector (mlogc) v2.5.12 Usage: mlogc [options] /path/to/the/mlogc.conf Options: -f Force depletion of queue on exit -v Version information -h This help ====================8<===================================== Right - so I change the REAL_MLOGC variable to read: REAL_MLOGC="/usr/bin/mlogc /etc/mlogc.conf" Now the script works, but when used as a wrapper to the original call in /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf (i.e. #SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" (where the commented out line is the original call to mlogc) restarting apache fails: # service httpd restart Stopping httpd: [OK] Starting httpd: [FAILED] What should I try next? Thanks again for all your help so far. Mark |
From: Brian R. <bre...@gm...> - 2010-08-22 03:21:09
|
On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent <mis...@bl...> wrote: > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent >> > <mis...@bl...> wrote: >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: >> > >> Syntax looks correct. Try adding a "set -x" on a line just after the >> > >> #!/bin/sh line which will show all the commands being executed with >> > >> vars substituted and may show the issue. >> > >> >> > >> -B >> > > >> > > Sorry - that didn't help... >> > >> > Ahh, but it did :) >> > >> > > >> > > # ./mlogc-strace.sh >> > > + REAL_MLOGC=/usr/bin/mlogc >> > > + LOGFILE=/tmp/mlogc-strace.log >> > > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log >> > >> > It shows that the email wrapped my script and put the >> > >> > $REAL_MLOGC "$@" >> > >> > On a line by itself (ie not executed after the exec), when it was >> > supposed to be at the end of the strace line. Try this version with >> > the line continuations :) >> > >> > #!/bin/sh >> > REAL_MLOGC=/usr/local/bin/mlogc >> > LOGFILE=/tmp/mlogc-strace.log >> > exec strace \ >> > -f -e trace=open,close,read,write \ >> > -s 8192 -o $LOGFILE \ >> > $REAL_MLOGC "$@" >> > >> > -B >> >> OK - Brilliant! >> >> Sorry that was my bad. I misunderstood what that line was doing. >> >> Now. I'm afraid I'm just about to leave for the airport, so I won't have >> a chance to try this until I'm back next weekend. I could try to ssh >> into my server from an internet cafe somewhere, but there is a very real >> possibility that my wife will divorce me. So... I'll report back next >> week... > > Right... Back from my hols... Hope you had fun. > > OK - So the the line continuations this is what I get... > > ====================8<===================================== > > # ./mlogc-strace.sh > + REAL_MLOGC=/usr/bin/mlogc > + LOGFILE=/tmp/mlogc-strace.log > + exec /usr/bin/strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log /usr/bin/mlogc > ModSecurity Log Collector (mlogc) v2.5.12 > Usage: mlogc [options] /path/to/the/mlogc.conf > > Options: > -f Force depletion of queue on exit > -v Version information > -h This help > > ====================8<===================================== > > > Right - so I change the REAL_MLOGC variable to read: > REAL_MLOGC="/usr/bin/mlogc /etc/mlogc.conf" No, no, that was correct. Don't add the conf file in the file - it is already added from the commandline (ie the "$@"). You should have run: ./mlogc-strace.sh /etc/mlogc.conf > Now the script works, but when used as a wrapper to the original call > in /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf (i.e. > #SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" > > (where the commented out line is the original call to mlogc) restarting > apache fails: > # service httpd restart > Stopping httpd: [OK] > Starting httpd: [FAILED] > > What should I try next? Yeah, it added the conf file twice (once in the script and then again when "$@" expanded to it :) > > Thanks again for all your help so far. No prob. -B |
From: Arthur D. <mis...@bl...> - 2010-08-22 07:53:23
|
On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: > On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent > <mis...@bl...> wrote: > > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: > >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > >> > <mis...@bl...> wrote: > >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > >> > >> Syntax looks correct. Try adding a "set -x" on a line just after the > >> > >> #!/bin/sh line which will show all the commands being executed with > >> > >> vars substituted and may show the issue. > >> > >> > >> > >> -B > >> > > > >> > > Sorry - that didn't help... > >> > > >> > Ahh, but it did :) > >> > > >> > > > >> > > # ./mlogc-strace.sh > >> > > + REAL_MLOGC=/usr/bin/mlogc > >> > > + LOGFILE=/tmp/mlogc-strace.log > >> > > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log > >> > > >> > It shows that the email wrapped my script and put the > >> > > >> > $REAL_MLOGC "$@" > >> > > >> > On a line by itself (ie not executed after the exec), when it was > >> > supposed to be at the end of the strace line. Try this version with > >> > the line continuations :) > >> > > >> > #!/bin/sh > >> > REAL_MLOGC=/usr/local/bin/mlogc > >> > LOGFILE=/tmp/mlogc-strace.log > >> > exec strace \ > >> > -f -e trace=open,close,read,write \ > >> > -s 8192 -o $LOGFILE \ > >> > $REAL_MLOGC "$@" > >> > > >> > -B > >> > >> OK - Brilliant! > >> > >> Sorry that was my bad. I misunderstood what that line was doing. > >> > >> Now. I'm afraid I'm just about to leave for the airport, so I won't have > >> a chance to try this until I'm back next weekend. I could try to ssh > >> into my server from an internet cafe somewhere, but there is a very real > >> possibility that my wife will divorce me. So... I'll report back next > >> week... > > > > Right... Back from my hols... > > Hope you had fun. > > > > > OK - So the the line continuations this is what I get... > > > > ====================8<===================================== > > > > # ./mlogc-strace.sh > > + REAL_MLOGC=/usr/bin/mlogc > > + LOGFILE=/tmp/mlogc-strace.log > > + exec /usr/bin/strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log /usr/bin/mlogc > > ModSecurity Log Collector (mlogc) v2.5.12 > > Usage: mlogc [options] /path/to/the/mlogc.conf > > > > Options: > > -f Force depletion of queue on exit > > -v Version information > > -h This help > > > > ====================8<===================================== > > > > > > Right - so I change the REAL_MLOGC variable to read: > > REAL_MLOGC="/usr/bin/mlogc /etc/mlogc.conf" > > No, no, that was correct. Don't add the conf file in the file - it is > already added from the commandline (ie the "$@"). You should have > run: > > ./mlogc-strace.sh /etc/mlogc.conf OK - That works - but what about the SecAuditlog command? (see below). How does ModSec know to use mlogc for logging unless the SecAuditlog command is invoked from modsecurity_crs_10_config.conf - which is where mlogc is normally started? I only tried running the script directly from the command line when restarting apache failed. (calling the wrapper script instead of the normal call to mlogc in modsecurity_crs_10_config.conf) > > > Now the script works, but when used as a wrapper to the original call > > in /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf (i.e. > > #SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" > > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" > > > > (where the commented out line is the original call to mlogc) restarting > > apache fails: > > # service httpd restart > > Stopping httpd: [OK] > > Starting httpd: [FAILED] > > > > What should I try next? > > Yeah, it added the conf file twice (once in the script and then again > when "$@" expanded to it :) > > > > > Thanks again for all your help so far. > > No prob. > > -B |
From: Brian R. <bre...@gm...> - 2010-08-22 20:07:40
|
On Sun, Aug 22, 2010 at 12:52 AM, Arthur Dent <mis...@bl...> wrote: > On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: >> On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent >> <mis...@bl...> wrote: >> > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: >> >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: >> >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent >> >> > <mis...@bl...> wrote: >> >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: >> >> > >> Syntax looks correct. Try adding a "set -x" on a line just after the >> >> > >> #!/bin/sh line which will show all the commands being executed with >> >> > >> vars substituted and may show the issue. >> >> > >> >> >> > >> -B >> >> > > >> >> > > Sorry - that didn't help... >> >> > >> >> > Ahh, but it did :) >> >> > >> >> > > >> >> > > # ./mlogc-strace.sh >> >> > > + REAL_MLOGC=/usr/bin/mlogc >> >> > > + LOGFILE=/tmp/mlogc-strace.log >> >> > > + exec strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log >> >> > >> >> > It shows that the email wrapped my script and put the >> >> > >> >> > $REAL_MLOGC "$@" >> >> > >> >> > On a line by itself (ie not executed after the exec), when it was >> >> > supposed to be at the end of the strace line. Try this version with >> >> > the line continuations :) >> >> > >> >> > #!/bin/sh >> >> > REAL_MLOGC=/usr/local/bin/mlogc >> >> > LOGFILE=/tmp/mlogc-strace.log >> >> > exec strace \ >> >> > -f -e trace=open,close,read,write \ >> >> > -s 8192 -o $LOGFILE \ >> >> > $REAL_MLOGC "$@" >> >> > >> >> > -B >> >> >> >> OK - Brilliant! >> >> >> >> Sorry that was my bad. I misunderstood what that line was doing. >> >> >> >> Now. I'm afraid I'm just about to leave for the airport, so I won't have >> >> a chance to try this until I'm back next weekend. I could try to ssh >> >> into my server from an internet cafe somewhere, but there is a very real >> >> possibility that my wife will divorce me. So... I'll report back next >> >> week... >> > >> > Right... Back from my hols... >> >> Hope you had fun. >> >> > >> > OK - So the the line continuations this is what I get... >> > >> > ====================8<===================================== >> > >> > # ./mlogc-strace.sh >> > + REAL_MLOGC=/usr/bin/mlogc >> > + LOGFILE=/tmp/mlogc-strace.log >> > + exec /usr/bin/strace -f -e trace=open,close,read,write -s 8192 -o /tmp/mlogc-strace.log /usr/bin/mlogc >> > ModSecurity Log Collector (mlogc) v2.5.12 >> > Usage: mlogc [options] /path/to/the/mlogc.conf >> > >> > Options: >> > -f Force depletion of queue on exit >> > -v Version information >> > -h This help >> > >> > ====================8<===================================== >> > >> > >> > Right - so I change the REAL_MLOGC variable to read: >> > REAL_MLOGC="/usr/bin/mlogc /etc/mlogc.conf" >> >> No, no, that was correct. Don't add the conf file in the file - it is >> already added from the commandline (ie the "$@"). You should have >> run: >> >> ./mlogc-strace.sh /etc/mlogc.conf > > OK - That works - but what about the SecAuditlog command? (see below). > How does ModSec know to use mlogc for logging unless the SecAuditlog > command is invoked from modsecurity_crs_10_config.conf - which is where > mlogc is normally started? > > I only tried running the script directly from the command line when > restarting apache failed. (calling the wrapper script instead of the > normal call to mlogc in modsecurity_crs_10_config.conf) 1) Do not put the conf filename in the wrapper script 2) Using this should then be fine as long at that script is executable (and appears to be if you can run it directly) SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" Provided you do not have other protections like chroot in place. Questions: 1) Running "/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" works directly? 2) What errors are showing in the apache error log? -B > >> >> > Now the script works, but when used as a wrapper to the original call >> > in /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf (i.e. >> > #SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" >> > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" >> > >> > (where the commented out line is the original call to mlogc) restarting >> > apache fails: >> > # service httpd restart >> > Stopping httpd: [OK] >> > Starting httpd: [FAILED] >> > >> > What should I try next? >> >> Yeah, it added the conf file twice (once in the script and then again >> when "$@" expanded to it :) >> >> > >> > Thanks again for all your help so far. >> >> No prob. >> >> -B > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Appliances, Rule Sets and Support: > http://www.modsecurity.org/breach/index.html > |
From: Arthur D. <mis...@bl...> - 2010-08-22 20:40:25
|
On Sun, 2010-08-22 at 13:07 -0700, Brian Rectanus wrote: > On Sun, Aug 22, 2010 at 12:52 AM, Arthur Dent > <mis...@bl...> wrote: > > On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: > >> On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent > >> <mis...@bl...> wrote: > >> > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: > >> >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > >> >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > >> >> > <mis...@bl...> wrote: > >> >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: snip... > 1) Do not put the conf filename in the wrapper script Confirmed. > 2) Using this should then be fine as long at that script is executable > (and appears to be if you can run it directly) Yes I appear to be able to run the script directly, but no, I can't restart apache with it in place. > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" Yes that's exactly how it appears in modsecurity_crs_10_config.conf. > Provided you do not have other protections like chroot in place. Doh! - This is where we came in... Selinux! Sorry - Wasn't thinking. Apache can't access /root/ with selinux controls in place! I moved it to /usr/bin/ (same place as the real mlogc) and it works. Sorry for the noise. Right. Now I'm going to try to trigger the selinux avc with mlogc and I'll post the strace log... Thanks for your patience! Mark |
From: Arthur D. <mis...@bl...> - 2010-08-22 21:59:05
|
On Sun, 2010-08-22 at 21:40 +0100, Arthur Dent wrote: > On Sun, 2010-08-22 at 13:07 -0700, Brian Rectanus wrote: > > On Sun, Aug 22, 2010 at 12:52 AM, Arthur Dent > > <mis...@bl...> wrote: > > > On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: > > >> On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent > > >> <mis...@bl...> wrote: > > >> > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: > > >> >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > > >> >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > > >> >> > <mis...@bl...> wrote: > > >> >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > > snip... > > > 1) Do not put the conf filename in the wrapper script > > Confirmed. > > > 2) Using this should then be fine as long at that script is executable > > (and appears to be if you can run it directly) > > Yes I appear to be able to run the script directly, but no, I can't > restart apache with it in place. > > > > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" > > Yes that's exactly how it appears in modsecurity_crs_10_config.conf. > > > Provided you do not have other protections like chroot in place. > > Doh! - This is where we came in... Selinux! > > Sorry - Wasn't thinking. Apache can't access /root/ with selinux > controls in place! > > I moved it to /usr/bin/ (same place as the real mlogc) and it works. > Sorry for the noise. > > Right. Now I'm going to try to trigger the selinux avc with mlogc and > I'll post the strace log... > > Thanks for your patience! > > > Mark OK Brian - This was not as easy as I'd hoped. As soon as I got strace working from modsecurity I got about 3,500 selinux avc denials for the strace process - Literally - it went mad. I created a local policy to allow the strace process which I hope did not mask the effects we were originally looking for. Anyway, I re-injected an earlier modsec event which caused the selinux denials as mlogc attempted to write to /etc/pki/nssdb/cert9.db and /etc/pki/nssdb/key4.db. It did indeed trigger those denials. I have captured the strace log but a) it is a bit big and b) it contains some personal information. Can I send it directly to you please? Thanks again for all your help... Mark |
From: Brian R. <bre...@gm...> - 2010-08-31 17:25:55
|
On Sun, Aug 22, 2010 at 2:35 PM, Arthur Dent <mis...@bl...> wrote: > On Sun, 2010-08-22 at 21:40 +0100, Arthur Dent wrote: >> On Sun, 2010-08-22 at 13:07 -0700, Brian Rectanus wrote: >> > On Sun, Aug 22, 2010 at 12:52 AM, Arthur Dent >> > <mis...@bl...> wrote: >> > > On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: >> > >> On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent >> > >> <mis...@bl...> wrote: >> > >> > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: >> > >> >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: >> > >> >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent >> > >> >> > <mis...@bl...> wrote: >> > >> >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: >> >> snip... >> >> > 1) Do not put the conf filename in the wrapper script >> >> Confirmed. >> >> > 2) Using this should then be fine as long at that script is executable >> > (and appears to be if you can run it directly) >> >> Yes I appear to be able to run the script directly, but no, I can't >> restart apache with it in place. >> >> >> > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" >> >> Yes that's exactly how it appears in modsecurity_crs_10_config.conf. >> >> > Provided you do not have other protections like chroot in place. >> >> Doh! - This is where we came in... Selinux! >> >> Sorry - Wasn't thinking. Apache can't access /root/ with selinux >> controls in place! >> >> I moved it to /usr/bin/ (same place as the real mlogc) and it works. >> Sorry for the noise. >> >> Right. Now I'm going to try to trigger the selinux avc with mlogc and >> I'll post the strace log... >> >> Thanks for your patience! >> >> >> Mark > > OK Brian - This was not as easy as I'd hoped. As soon as I got strace > working from modsecurity I got about 3,500 selinux avc denials for the > strace process - Literally - it went mad. > > I created a local policy to allow the strace process which I hope did > not mask the effects we were originally looking for. > > Anyway, I re-injected an earlier modsec event which caused the selinux > denials as mlogc attempted to write to /etc/pki/nssdb/cert9.db > and /etc/pki/nssdb/key4.db. It did indeed trigger those denials. > > I have captured the strace log but a) it is a bit big and b) it contains > some personal information. > > Can I send it directly to you please? > > Thanks again for all your help... 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 |
From: Arthur D. <mis...@bl...> - 2010-08-31 21:51:42
|
On Tue, 2010-08-31 at 10:25 -0700, Brian Rectanus wrote: > On Sun, Aug 22, 2010 at 2:35 PM, Arthur Dent > <mis...@bl...> wrote: > > On Sun, 2010-08-22 at 21:40 +0100, Arthur Dent wrote: > >> On Sun, 2010-08-22 at 13:07 -0700, Brian Rectanus wrote: > >> > On Sun, Aug 22, 2010 at 12:52 AM, Arthur Dent > >> > <mis...@bl...> wrote: > >> > > On Sat, 2010-08-21 at 20:21 -0700, Brian Rectanus wrote: > >> > >> On Sat, Aug 21, 2010 at 12:54 PM, Arthur Dent > >> > >> <mis...@bl...> wrote: > >> > >> > On Mon, 2010-08-16 at 10:46 +0100, Arthur Dent wrote: > >> > >> >> On Mon, 2010-08-16 at 00:33 -0700, Brian Rectanus wrote: > >> > >> >> > On Sun, Aug 15, 2010 at 12:32 PM, Arthur Dent > >> > >> >> > <mis...@bl...> wrote: > >> > >> >> > > On Sun, 2010-08-15 at 12:25 -0700, Brian Rectanus wrote: > >> > >> snip... > >> > >> > 1) Do not put the conf filename in the wrapper script > >> > >> Confirmed. > >> > >> > 2) Using this should then be fine as long at that script is executable > >> > (and appears to be if you can run it directly) > >> > >> Yes I appear to be able to run the script directly, but no, I can't > >> restart apache with it in place. > >> > >> > >> > SecAuditLog "|/root/scripts/testdir/mlogc-strace.sh /etc/mlogc.conf" > >> > >> Yes that's exactly how it appears in modsecurity_crs_10_config.conf. > >> > >> > Provided you do not have other protections like chroot in place. > >> > >> Doh! - This is where we came in... Selinux! > >> > >> Sorry - Wasn't thinking. Apache can't access /root/ with selinux > >> controls in place! > >> > >> I moved it to /usr/bin/ (same place as the real mlogc) and it works. > >> Sorry for the noise. > >> > >> Right. Now I'm going to try to trigger the selinux avc with mlogc and > >> I'll post the strace log... > >> > >> Thanks for your patience! > >> > >> > >> Mark > > > > OK Brian - This was not as easy as I'd hoped. As soon as I got strace > > working from modsecurity I got about 3,500 selinux avc denials for the > > strace process - Literally - it went mad. > > > > I created a local policy to allow the strace process which I hope did > > not mask the effects we were originally looking for. > > > > Anyway, I re-injected an earlier modsec event which caused the selinux > > denials as mlogc attempted to write to /etc/pki/nssdb/cert9.db > > and /etc/pki/nssdb/key4.db. It did indeed trigger those denials. > > > > I have captured the strace log but a) it is a bit big and b) it contains > > some personal information. > > > > Can I send it directly to you please? > > > > Thanks again for all your help... > > 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 OK Thanks Brian. I'm not sure I have the energy to take this through curl and beyond. I have just created a local selinux policy to allow it through, and I will leave it at that... Thanks again for all your help. Apologies for bugging you during your busy time... Mark |