SELinux & modsecurity-nginx about modsecurity-nginx HOT 33 CLOSED

Thanks @zimmerle for your comment.
Actually I could compile ModSecurity with pcre which it was compiled by myself.

ldd /opt/ModSecurity/src/.libs/libmodsecurity.so | grep pcre
libpcre.so.1 => /usr/local/pcre/lib/libpcre.so.1 (0x00007f791052a000)

Now nginx starts and works fine and mosecurity rules work too expect when sometime when I restart nginx or the VM, nginx can't start and it gives me this error:
nginx: [emerg] "modsecurity_rules_file" directive Failed to open file: /var/log/modsec_audit.log Permission is denied.
I should remove /var/log/modsec_audit.log and then start nginx.

Also /var/log/audit/audit.log is filled with this error after each request.
type=AVC msg=audit(1543930775.545:39978): avc: denied { execmem } for pid=23370 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process

I will try pcre_jit off in my nginx config and let you know if the problem still exists.

I inserted pcre_jit off to my nginx config and it says:
nginx: [emerg] "modsecurity_rules_file" directive Failed to allocate shared memory (1): Permission denied
Now it doesn't even start without pcre_jit off and shows me the above error:(

I rebooted my VM and now it starts and work fine except errors in /var/log/audit/audit.log still appears.
I'm very confused now.

from modsecurity-nginx.

Hi @met3or,

That is an interesting question. It seems like pcre-jit makes usage of the execmem, I have saw other projects facing the same problem including cups. That might explain why you have the AVC on both versions.

I am not so sure if the AVC is somehow related to this shared memory piece that is returning the error for you. Do you mind to disable audit and debug logs to test it again? Just to check if you still got the AVC.

Other thing that will be interesting to know is if you have ModSecurity as a loadable module or if it is part of the same ELF as Nginx.

It will be good to check on the output of readelf. Like: readelf -l /path/to/nginx and readelf -l /path/to/libmodsecurity and a third one if you have ModSecurity-nginx compile as a loadable module. The output should be something similar to:

Elf file type is DYN (Shared object file)
Entry point 0x9bf60
There are 7 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000001b02d3 0x00000000001b02d3  R E    0x200000
  LOAD           0x00000000001b0980 0x00000000003b0980 0x00000000003b0980
                 0x000000000002c310 0x000000000002c6a8  RW     0x200000
  DYNAMIC        0x00000000001da188 0x00000000003da188 0x00000000003da188
                 0x0000000000000290 0x0000000000000290  RW     0x8
  NOTE           0x00000000000001c8 0x00000000000001c8 0x00000000000001c8
                 0x0000000000000024 0x0000000000000024  R      0x4
  GNU_EH_FRAME   0x000000000018d780 0x000000000018d780 0x000000000018d780
                 0x0000000000003974 0x0000000000003974  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x00000000001b0980 0x00000000003b0980 0x00000000003b0980
                 0x000000000002a680 0x000000000002a680  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table 
   01     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 
   02     .dynamic 
   03     .note.gnu.build-id 
   04     .eh_frame_hdr 
   05     
   06     .init_array .fini_array .jcr .data.rel.ro .dynamic .got 

from modsecurity-nginx.

Hi @zimmerle and thanks for taking an interest in this issue!

I commented out the following lines in ModSecurity.conf;

SecAuditLogType Serial
SecAuditLog /var/log/nginx/modsec_audit.log

And the issue had no longer presented itself upon nginx start, but to help provide further information on the topic I will give you the output from the readelf also:

# which nginx
/usr/sbin/nginx
# readelf -l /usr/sbin/nginx

Elf file type is EXEC (Executable file)
Entry point 0x44d015
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000003a45dc 0x00000000003a45dc  R E    200000
  LOAD           0x00000000003a4d78 0x00000000009a4d78 0x00000000009a4d78
                 0x0000000000031cd8 0x0000000000057fa8  RW     200000
  DYNAMIC        0x00000000003a4d98 0x00000000009a4d98 0x00000000009a4d98
                 0x0000000000000260 0x0000000000000260  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x00000000003431a8 0x00000000007431a8 0x00000000007431a8
                 0x000000000000e0d4 0x000000000000e0d4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x00000000003a4d78 0x00000000009a4d78 0x00000000009a4d78
                 0x0000000000000288 0x0000000000000288  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .jcr .dynamic .got

&&

# readelf -l /usr/lib64/libmodsecurity.so.3.0.0

Elf file type is DYN (Shared object file)
Entry point 0x9bce0
There are 7 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000001bc3ab 0x00000000001bc3ab  R E    200000
  LOAD           0x00000000001bc460 0x00000000003bc460 0x00000000003bc460
                 0x000000000002dc70 0x000000000002dfc8  RW     200000
  DYNAMIC        0x00000000001e71d8 0x00000000003e71d8 0x00000000003e71d8
                 0x0000000000000280 0x0000000000000280  RW     8
  NOTE           0x00000000000001c8 0x00000000000001c8 0x00000000000001c8
                 0x0000000000000024 0x0000000000000024  R      4
  GNU_EH_FRAME   0x0000000000197060 0x0000000000197060 0x0000000000197060
                 0x0000000000003b84 0x0000000000003b84  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x00000000001bc460 0x00000000003bc460 0x00000000003bc460
                 0x000000000002bba0 0x000000000002bba0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   01     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
   02     .dynamic
   03     .note.gnu.build-id
   04     .eh_frame_hdr
   05
   06     .init_array .fini_array .jcr .data.rel.ro .dynamic .got

I have the ModSecurity-nginx module built within this RPM of nginx and do not have the module available to readelf on.

Hope this information is found to be useful, thanks for your help!

David

from modsecurity-nginx.

(Just a quick note: PCRE-JIT now has an selinux compatible allocator in the svn trunk, but it has not released yet. If you want to try it I can help)

from modsecurity-nginx.

@zherczeg That would be fantastic if I could? :-)

from modsecurity-nginx.

I think ModSecurity uses pcre1, and these are its building steps:

Checkout:

svn co svn://vcs.exim.org/pcre/code/trunk pcre1

Setup:

cd pcre1
./autogen.sh

Configure:

export CFLAGS="-O2 -DSLJIT_PROT_EXECUTABLE_ALLOCATOR=1" ; \
  ./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties

This is just a demo configuration, feel free to modify it. I plan to add a build system configuration for defining SLJIT_PROT_EXECUTABLE_ALLOCATOR to make it user friendly.

Compile:

make

Make sure ModSecurity uses the compiled shared libraries. Perhaps setting up an LD_LIBRARY_PATH is the easiest for testing.

I can also share PCRE2 build steps if you need it.

from modsecurity-nginx.

Hi @met3or,

Did you had a chance to try it? I am assuming everything is working like expected. Please, re-open the issue if not.

from modsecurity-nginx.

@zherczeg - Unfortunately, I've just gotten around to testing this and the method I've gone to testing this is as follows:

Follow the steps provided:

I think ModSecurity uses pcre1, and these are its building steps:

Checkout:

svn co svn://vcs.exim.org/pcre/code/trunk pcre1
Setup:

cd pcre1
./autogen.sh
Configure:

export CFLAGS="-O2 -DSLJIT_PROT_EXECUTABLE_ALLOCATOR=1" ;
./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties
This is just a demo configuration, feel free to modify it. I plan to add a build system configuration for defining SLJIT_PROT_EXECUTABLE_ALLOCATOR to make it user friendly.

Compile:

make
Make sure ModSecurity uses the compiled shared libraries. Perhaps setting up an LD_LIBRARY_PATH is the easiest for testing.

I can also share PCRE2 build steps if you need it.

And then re-compiling libmodsecurity and nginx w/ libmodsecurity with a defined environmental variable for LD_LIBRARY_PATH and LD_RUN_PATH also of the path for PCRE1.

With this setup and SELinux enabled I am still encountering execmem conflicts in SELinux:

Raw Audit Messages
type=AVC msg=audit(1498728281.996:164185): avc:  denied  { execmem } for  pid=2332 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process

This may be due to me now following the instructions as intended however, so I am eager to hear any guidance that you may be able to provide.

Thanks for the advice and assistance so far though!

Let me know if you require further information,

Regards,

David

from modsecurity-nginx.

First we should confirm that the JIT compiler is working. After you compiled pcre, a test program called pcretest is created in the build directory. Run this application with -s+, compile a simple regex and match a simple pattern:

./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a

This would check whether the allocator is working.

from modsecurity-nginx.

@zherczeg - Agreed, and thanks for the swift response! :)

Here is an excerpt from my tests:

[root@x bin]# ./pcretest
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a
data>

[root@x bin]# ./pcretest
PCRE version 8.41-RC1 2017-06-13

  re> /c/
data> c
 0: c
data> /1/
No match
data> asd
No match
data> v
No match

So, it appears that it is working at least.

from modsecurity-nginx.

Hm, I don't see the -s+ after pcretest. Otherwise the interpreter is used.

from modsecurity-nginx.

@zherczeg - Oops, my mistake!

# ./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a

# ./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /s/
data> s
 0: s
data> d
No match
data>

from modsecurity-nginx.

Ok, so it seems working. The next step would be to compile pcre (clean build) without the SLJIT_PROT_EXECUTABLE_ALLOCATOR flag. If pcretest fails after that with execmem error it proves that the SELinux allocator is working. Then we should figure out which pcre library your modsecurity is using (maybe statically linked to the binary).

from modsecurity-nginx.

Hi @zherczeg,

I have now re-configured the PCRE package (following a clean RM of the existing library) with the below options;

export CFLAGS="-O2; \ 
./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties

And the results are the following

[root@modsecurity bin]# ./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a
data> b
No match

And to confirm that my device has SELinux set to enforcing:

# getenforce
Enforcing

Running lsof | grep pcre I can see the current PCRE library in use by nginx is the following:

nginx      2331                 root  mem       REG              253,2    398264     134177 /usr/lib64/libpcre.so.1.2.0
nginx      2332                nginx  mem       REG              253,2    398264     134177 /usr/lib64/libpcre.so.1.2.0

Which differs from the installed library which is /usr/local/lib/* location.

from modsecurity-nginx.

The pcretest program runs with the normal allocator? That is strange for me. Could you add --enable-shared=no to enforce static linking? Perhaps you could also run pcre_jit_test in the same directory. If it runs that is very strange.

from modsecurity-nginx.

Hi @zherczeg - Unforunately the pcre_jit_test does not compile into the /usr/local/bin directory with the other tools. I did however find it within the downloaded pcre1 svn directory:

# ./pcre_jit_test
Running JIT regression tests
  target CPU of SLJIT compiler: x86 64bit (little endian + unaligned)
  in  8 bit mode with UTF-8  enabled and ucp enabled:
  in 16 bit mode with UTF-16 enabled and ucp enabled:
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
....................................
All JIT regression tests are successfully passed.

So, now when configuring with --enable-shared=no

# export CFLAGS="-O2"; \
> ./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties --enable-shared=no

With these options enabled and configured, make & make install, running

/usr/local/bin/pcretest -s+

# ./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a
data> b
No match

from modsecurity-nginx.

I have no idea what is happening. The normal allocator should not work on SELinux (this is confirmed on some other systems) unless some configuration makes an exception. However, if the normal allocator does work, why do you get execmem errors? This is confusing for me.

from modsecurity-nginx.

To further test, I have rebooted the box with SELinux enabled, destroying the current pcre library, and re-installing the with following options defined:

# export CFLAGS="-O2"; \
> ./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties

pcre-8.41-RC1 configuration summary:

    Install prefix .................. : /usr/local
    C preprocessor .................. : gcc -E
    C compiler ...................... : gcc
    C++ preprocessor ................ : g++ -E
    C++ compiler .................... : g++
    Linker .......................... : /bin/ld -m elf_x86_64
    C preprocessor flags ............ :
    C compiler flags ................ : -pthread -O2 -fvisibility=hidden
    C++ compiler flags .............. : -O2 -fvisibility=hidden -fvisibility-inlines-hidden
    Linker flags .................... :
    Extra libraries ................. :

    Build 8 bit pcre library ........ : yes
    Build 16 bit pcre library ....... : yes
    Build 32 bit pcre library ....... : no
    Build C++ library ............... : yes
    Enable JIT compiling support .... : yes
    Enable UTF-8/16/32 support ...... : yes
    Unicode properties .............. : yes
    Newline char/sequence ........... : lf
    \R matches only ANYCRLF ......... : no
    EBCDIC coding ................... : no
    EBCDIC code for NL .............. : n/a
    Rebuild char tables ............. : no
    Use stack recursion ............. : yes
    POSIX mem threshold ............. : 10
    Internal link size .............. : 2
    Nested parentheses limit ........ : 250
    Match limit ..................... : 10000000
    Match limit recursion ........... : MATCH_LIMIT
    Build shared libs ............... : yes
    Build static libs ............... : yes
    Use JIT in pcregrep ............. : yes
    Buffer size for pcregrep ........ : 20480
    Link pcregrep with libz ......... : no
    Link pcregrep with libbz2 ....... : no
    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : no
    Valgrind support ................ : no
    Code coverage ................... : no

And following from a make & make install and executing the new binary:

/usr/local/bin/pcretest -s+
# ./pcretest -s+
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a
data> b
No match
data> /abcdef/
 0: a
data>
  re> /abcdef/
data> abcdef
 0: abcdef
data>
  re> /\w/
data> 2
 0: 2

None of which triggered any events from /var/log/audit/audit.log whilst the output of getenforce is:

# getenforce
Enforcing

I appreciate your help so far, and any further insight you may have would be tremendously useful :)

from modsecurity-nginx.

The configuration seems perfect. Honestly the default allocator must not work on SELinux since it allocates a page with write and executable attributes. Perhaps we could try the '-s++' option, which verifies whether JIT is used:

./pcretest -s++
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a (JIT)

If I compile pcre without JIT I get:

./pcretest -s++
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a

Anyway I do think we use JIT, and something prevents the error, maybe some special exception. Perhaps when you install the library, the permission applies to the newly installed files.

We could try what happens if you compile pcre with static (pass --enable-shared=no to configure) and do not install the library. Instead simply run the pcretest / pcre_jit_test in the build directory.

from modsecurity-nginx.

Hello @zherczeg

# /usr/local/bin/pcretest -s++
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a (JIT)
data> b
No match (JIT)

To confirm that JIT is being used. I will now go ahead and test the shared=no configure test,

pcre-8.41-RC1 configuration summary:

    Install prefix .................. : /usr/local
    C preprocessor .................. : gcc -E
    C compiler ...................... : gcc
    C++ preprocessor ................ : g++ -E
    C++ compiler .................... : g++
    Linker .......................... : /bin/ld -m elf_x86_64
    C preprocessor flags ............ :
    C compiler flags ................ : -pthread -O2 -fvisibility=hidden
    C++ compiler flags .............. : -O2 -fvisibility=hidden -fvisibility-inlines-hidden
    Linker flags .................... :
    Extra libraries ................. :

    Build 8 bit pcre library ........ : yes
    Build 16 bit pcre library ....... : yes
    Build 32 bit pcre library ....... : no
    Build C++ library ............... : yes
    Enable JIT compiling support .... : yes
    Enable UTF-8/16/32 support ...... : yes
    Unicode properties .............. : yes
    Newline char/sequence ........... : lf
    \R matches only ANYCRLF ......... : no
    EBCDIC coding ................... : no
    EBCDIC code for NL .............. : n/a
    Rebuild char tables ............. : no
    Use stack recursion ............. : yes
    POSIX mem threshold ............. : 10
    Internal link size .............. : 2
    Nested parentheses limit ........ : 250
    Match limit ..................... : 10000000
    Match limit recursion ........... : MATCH_LIMIT
    Build shared libs ............... : no
    Build static libs ............... : yes
    Use JIT in pcregrep ............. : yes
    Buffer size for pcregrep ........ : 20480
    Link pcregrep with libz ......... : no
    Link pcregrep with libbz2 ....... : no
    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : no
    Valgrind support ................ : no
    Code coverage ................... : no

from the following configure statement:

# export CFLAGS="-O2"; \
> ./configure --enable-pcre16 --enable-jit --enable-utf --enable-unicode-properties --enable-shared=no

To confirm current working directory is not the installed directory:

# pwd
/home/test/pcre1
./pcretest -s++
PCRE version 8.41-RC1 2017-06-13

  re> /a/
data> a
 0: a (JIT)
data> b
No match (JIT)

With seemingly no SELinux breaks, and when running:

./pcre_jit_test
Running JIT regression tests
  target CPU of SLJIT compiler: x86 64bit (little endian + unaligned)
  in  8 bit mode with UTF-8  enabled and ucp enabled:
  in 16 bit mode with UTF-16 enabled and ucp enabled:
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
....................................
All JIT regression tests are successfully passed.

pcre1]# getenforce
Enforcing

All tests are passed successfully. How bizarre!

from modsecurity-nginx.

@zherczeg

I would like to report that I've found a minor work-around to this for the time being which may result in issues later down the line, but we'll see.

I have compiled the latest version of PCRE1 without JIT support, and applied this to both nginx + libmodsecurity, and with the correct SELinux contexts, ModSecurity is logging correctly and without SELinux permission issues.

I will keep an eye open for updates to PCRE for which the sealloc is correctly implemented.

Thanks for your assistance with this!

from modsecurity-nginx.

Hello @met3or ,

I've just compiled libmodsecurity and the nginx connector on CentOS 7, and I'm running into the same SELinux errors as you :

type=AVC msg=audit(1507474834.631:3533495): avc: denied { execmem } for pid=10563 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=syste m_u:system_r:httpd_t:s0 tclass=process type=SYSCALL msg=audit(1507474834.631:3533495): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=10562 pid=10563 auid =4294967295 uid=995 gid=993 euid=995 suid=995 fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj= system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1507474834.632:3533496): avc: denied { execmem } for pid=10563 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=syste m_u:system_r:httpd_t:s0 tclass=process type=SYSCALL msg=audit(1507474834.632:3533496): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=10562 pid=10563 auid =4294967295 uid=995 gid=993 euid=995 suid=995 fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj= system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1507474834.801:3533497): avc: denied { execmem } for pid=10563 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=syste m_u:system_r:httpd_t:s0 tclass=process type=SYSCALL msg=audit(1507474834.801:3533497): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=10562 pid=10563 auid =4294967295 uid=995 gid=993 euid=995 suid=995 fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj= system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1507474834.801:3533498): avc: denied { execmem } for pid=10563 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=syste m_u:system_r:httpd_t:s0 tclass=process

Reading from your comments, it seems you've been able to circumvent these problems by recompiling a library (pcre-devel ?) and linking modsecurity on it.

Could you please provide some more details on how you managed to make ModSecurity work with SElinux ? I have to admit that it's quiet complicated for me to understand the actions you implemented.

Thank you,

Antoine

from modsecurity-nginx.

@an-toine

Hi Antoine, to clarify, yes. To resolve the execmem SELinux policy violation I have to compile PCRE using the latest OS supported version without JIT support (as it is JIT which is causing the execmem issue).

Whilst not ideal, until the issue with which the way JIT is supported in PCRE is resolved, this is a needed change.

%configure \
    --disable-jit \
    --enable-pcretest-libreadline --enable-utf --enable-unicode-properties \
    --enable-pcre8 --enable-pcre16 --enable-pcre32

The above are the flags which I currently run when compiling the version. Please note, you will then need to re-compile ModSecurity and ensure that it is compiled referencing this new version of PCRE.

Additional changes that I had recommended to the logging (specific to Parallel logging) which caused issue has been added to the ModSecurity v3/master branch so with the changes to the PCRE version, this should allow you to then write with SELinux enabled.

Let me know if you still have issue,

Thanks,

David

from modsecurity-nginx.

I am closing this issue, as this issue as proved to be in PCRE. Although, I will keep it open for discussion as you guys may find some progress with PCRE.

from modsecurity-nginx.

@met3or
Thank you for your answer, I've successfully compiled and installed PCRE without JIT support. To avoid any conflict on my system, I've prefixed the installation to /usr/local/pcre/pcre-modsecurity/.

However I have an issue while linking libmodsecurity to /usr/local/pcre/pcre-modsecurity/lib64/libpcre.so.1.

I use this configure line with no luck :

%configure --with-pcre=/usr/local/pcre/pcre-modsecurity/bin/pcre-config

The library outputted is still linked to my system PCRE version :

$ ldd rpmbuild/BUILDROOT/modsecurity-3.0.0-2.rc1.x86_64/usr/lib64/libmodsecurity.so | grep pcre
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ffae6867000)

How did you manage to link your modsecurity version to the correct pcre library, without JIT support ?

Thank you,

Antoine

from modsecurity-nginx.

@met3or
Hi

Isn't it enough to use below Nginx directive?
pcre_jit off;

thanks

from modsecurity-nginx.

@met3or
Hi

Isn't it enough to use below Nginx directive?
pcre_jit off;

thanks

See #127 (comment)

from modsecurity-nginx.

@met3or
Thank you for your answer, I've successfully compiled and installed PCRE without JIT support. To avoid any conflict on my system, I've prefixed the installation to /usr/local/pcre/pcre-modsecurity/.

However I have an issue while linking libmodsecurity to /usr/local/pcre/pcre-modsecurity/lib64/libpcre.so.1.

I use this configure line with no luck :

%configure --with-pcre=/usr/local/pcre/pcre-modsecurity/bin/pcre-config

The library outputted is still linked to my system PCRE version :

$ ldd rpmbuild/BUILDROOT/modsecurity-3.0.0-2.rc1.x86_64/usr/lib64/libmodsecurity.so | grep pcre
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ffae6867000)

How did you manage to link your modsecurity version to the correct pcre library, without JIT support ?

Thank you,

Antoine

I have same problem. Any ideas on this?

from modsecurity-nginx.

Hi @aminvakil,

Regardless the version that ModSecurity was compiled, during run time it will pick the one used by nginx, as they share the process space. Why not use pcre_jit off;?

from modsecurity-nginx.

Hi @aminvakil, You have to tell your SELinux that nginx needs permission to write into those files. I guess, that by default it came with a nginx profile that does not take into consideration ModSecurity log files, therefore you have to change the profile to address it manually.

from modsecurity-nginx.

@zimmerle I know it isn't something that has to do with modsecurity, but can you explain a little more, because I supposed this permission was fine.
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 modsec_audit.log

Should I set owner of file nginx?

from modsecurity-nginx.

Sorry @aminvakil, not an expert on SELinux :(

from modsecurity-nginx.

Thanks @zimmerle.
I will trying changing owner of file to nginx and see if the problem still comes up.

from modsecurity-nginx.