Permission problems using Apache2 MPM ITK

[derhansen]

With Apache2 MPM ITK, every virtual host can run under a separate uid and gid. Using Apache2 MPM ITK with ModSecurity results in some error entries in the audit log because of missing permissions.

The Problem is, that the DBM file can't be accessed/written, because the default permissions to the files are 0640. This results in the situation, that only one virtual host is able to initially write the DBM files (if they do not exist). All other virtual hosts are not able to read/write to the DB; files resulting in the following messages in the audit log

Message: collections_remove_stale: Failed to access DBM file "/tmp//global": Permission denied
Message: collections_remove_stale: Failed to access DBM file "/tmp//ip": Permission denied

When you set the DBM file world writeable, then the above errors are not logged any more and each virtual host can access the DBM file.

The audit log still shows the following error, which I was not able to reproduce/fix

Message: Audit log: Failed to lock global mutex: Permission denied

It seems there is a general problem when running virtual hosts as different users with mod MPM ITK or mod RUID, as the global mutex problem is already filed here #454

It would be great if you could define SecDataDir also in the VHOST scope or if file permissions to all DBM files could be set in the configuration file. Also it would be great if the global mutex problem could be resolved.

If I can help debugging the global mutex problem, don't hesitate to contact me.

[michalzubkowicz]

Bump, same problem here.

[shawnholt]

me to - is there a good workaround? Happens in CPANEL with ruid2 and moditk ITK MPM

[manuel-sousa]

Same issue. Cpanel recently made a clever workaround using the owner of Apache as a part of the audit log when SecAuditLogType Concurrent.

This solves the mutex lock since for all effects each user is accessing a different log path.

They haven't made that change on the SecDataDir though and my programming knowledge ain't that good but it seems to be it would be more difficult since the object from which they retrieve the uid/name from isn't available at the functions used to write/read data.

It would be nice if modsecurity provided this as a feature since it has been a limitation when implementing modsecurity in a shared hosting environment.

[meatlayer]

Somebody knows a solution?
Probably in an initial code to change the user by an example -http://qiita.com/albatross/items/5b9034c80f9c49519442

[boerm]

For what it is worth, we just experienced the same kinds of errors in ModSec's audit log, and traced it to changes made in an SELinux package update that were preventing httpd from accessing those files.

[ju5t]

I have tried writing a patch for this issue, but I'm not really familiar with c let alone Apache's modular structure, that was certainly interesting. I did come up with a patch that seems to work mpm-itk, but doesn't work for mod_ruid2 for example. The difficulty being the fact that when it retrieves information on a certain variable in modsecurity in a certain phase it does this when mod_ruid2 hasn't made the switch to right user yet. It seems that mpm-itk is switching a lot earlier, but the very first request after it has idled for a while is still seen as the Apache user. I'm not sure how this would behave on a busier server with more users as well.

The patch can be found here: https://gist.github.com/ju5t/0d61ee80b23f0987d65e.

[shawnholt]

As of 4/27/2015 this issue is still not resolved. Cpanel claims it is a SpiderLabs issue in this thread:
Hello,

Much of the issue is related to limitations with Mod_Security itself with regard to shared storage and handlers like Mod_ruid2 and MPM-ITK. It's not something that cPanel can really solve, but that being said, the case is still open in order to find the best possible way to avoid these types of issues for customers"
ref: https://forums.cpanel.net/threads/modsecurity-rule-processing-failed.453321

Also xref: #454

[bartoszg]

As for now 19/01/2016 the problem still remains.

ModSecurity: collection_store: Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied
ModSecurity: Geo Lookup: Failed to lock proc mutex: Identifier removed

[sydro]

same problem here with mod_ruid2

[sydro]

Add patch in @ju5t comment [link], then recompile and it works!

My configuration was:

• ubuntu 14.04.4
• apache 2.4.7-1ubuntu4.11
• libapache2-mod-ruid2 0.9.8-3
• libapache2-mod-security2 2.7.7-2 (rebuilded)

[shawnholt]

Its a shame that now CPANEL is forcing you to disable modsec if you want to use ruid2 or itk due to this bug that they claim has not been addressed by Spiderlabs or others. IMO this will open a gaping hole in security. They refuse to even test the patch as they say it is not widely adopted yet. I wonder if CPANEL is even watching this thread and hope the figure-pointing ends and a solution is developed.