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.

[Spork-Schivago]

Ju5t,

Which problem does your patch fix? The Geo Lookup: Failed to lock proc mutex: Identifier removed issue or the Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied issue?

From a quick glance at your patch, it looks like maybe it fixes the DBM file permission denied issue. Is that correct? Also, has anyone tried it for an extended period of time and noticed any negative effects?

Thanks!

[Ogy]

bump
my workaround is set all to 777 via cron_daily
this is insane

[ju5t]

@Spork-Schivago it should solve the file permission denied issue. I know that the DirectAdmin control panel includes it in their ModSecurity implementation. I would assume that accounts for a reasonable number of servers.

We're using it ourselves too ever since 2014 and haven't seen any side effects.

[Spork-Schivago]

Thank you Ju5t. Still no fix for the modruid2 issues though, correct? So even with the patch, I still won't be able to use modruid2.

[ju5t]

@Spork-Schivago I wrote a patch for that too. I've raised a pull request for it but unfortunately it hasn't been accepted yet. See mind04/mod-ruid2#8 for more details.

[zimmerle]

Marking @ju5t's patch to be discussed in our next team meeting. Candidate for v2.9.2. The date is was not set yet.

[Spork-Schivago]

Zimmerle,

Do you know if @ju5t's first patch is already implemented? If not, does your team plan on discussing implementing both patches in v2.9.2? Thanks!

[meatlayer]

If anyone is interested.
We use this patch on hosting servers more 2 years, where total the number of users and sites >= 30000. Used this for apache2-itk and not found any problems all this time of use.

[Rod-Gomes]

Thanks @rendername .
Do not have any updates on this issue yet?
It's been three years!

[meatlayer]

@Rod-Gomes, Apparently not. In the main branch never no one sent a pull request, but this patch really solves problem as a minimum when using the apache itk.

[ju5t]

I've never sent in a pull request because I think it can be improved. In the end I'm not a C developer and my knowledge of Apache's internals is limited. I can raise a pull request if it helps.

@zimmerle wrote in August that the patch would be up for discussion in version 2.9.2. This version isn't released yet. An update is more than welcome.

[pa-de-solminihac]

@ju5t your patch looks great, and would be really useful. I think you should raise a pull request!

[victorhora]

The global mutex is optional since 112ba45 (included in 2.9.2 release)

@ju5t I've pushed your patch as PR #1912. It's tagged for review for 2.9.3.

Thanks all for your contributions :)

[ju5t]

@victorhora awesome! Thanks!