Mod RUID 2 and ModSecurity

[KurtN.]

I would strongly consider changing the directory to something specific to your ruleset, as opposed to using /tmp. For example, the comment above mentioned placing it in /var/asl/data/msa.

If you change it to that directory then try updating your /etc/cagefs/cagefs.mp file with the following: /var/asl/data/msa

 

[manuel.sousa]

Are you using CloudLinux with CageFS?

Hello Kurt,

I'm seeing the same issue with CentOS without CageFS.

As I understand the problem is CPanel solved the log file by modifying modsecurity source to append the username of the apache process to the directory path of the log files (great ideia btw) but hasn't done the same thing for the secDataDir. (CPanel changes @File modsecurity-apache/apache2/msc_logging.c')

For the secDataDir the first request owner still gets to create the files but all others requests from other owners get access denied since it's a file from a different owner and without access permissions.

My programming knowledge ain't that good but it should be on 'persist_dbm.c'. Problem is the structure which provides the UID isn't passed on that function and as such the changes required might require more changes in mod_security code.

As a workaround and easier fix it should be possible to change the code to create the file as a shared file with different permissions (this isn't secure as each user could have impact on another).

If anyone has a solution for this or a better approach please advise, as it stand no rules that make use of secDataDir are working.

Regards,
Manuel

 

[KurtN.]

Hi Manuel, thanks for the feedback.

After briefly looking at the mod_security plugin, I also do not see an easy alternative given mod_security's current implementation. A few possibilities could be (NOTE: this is not an exhaustive list):

1. World-writable DBM: This requires a modification to mod_security to prevent the file from being forced as 640. It would also be a security violation since this would allow anyone to write to the file and as-such, would not be a good approach.
2. Per-user DBM (without CageFS): This would also require a modification to mod_security, thus forcing it to write to an alternative directory. Unfortunately, this would have the unintended consequence of writing to a path that is different than what was specified by the rule itself. It could also have other unintended consequences with respect to file/directory creation.
3. Per-user DBM (with CageFS): CageFS appears to have the functionality necessary to achieve this without any modifications to mod_security. The instructions for this are defined in the CloudLinux documentation, under Per user virtual mount points. Note: I have not tested this approach yet.

 

[jhawkins003]

We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs?

Another way of asking this is - do we effectively have to choose between the two technologies?

 

[KurtN.]

We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs?

Another way of asking this is - do we effectively have to choose between the two technologies?

Yes, if you're using Mod Security rules that need the DBM functionality.
No, if you're not using those kinds of rules.

 

[WillDashwood]

I'm using the free rules from Comodo. Is there an easy way of detecting which rules use DBM so I can just leave those disabled?

 

[Recifier]

I was wondering if there is an internal case number for fixing this issue and any expected release timeframe?

Is there any way for us to track progress on this case?

 

[cPanelMichael]

I was wondering if there is an internal case number for fixing this issue and any expected release timeframe?

Is there any way for us to track progress on this case?

Could you elaborate on the specific issue you are still encountering at this time?

Thank you.

 

[Recifier]

The same problem as the last few posters. Creating a ModSecurity rule that uses DBM while Mod_RUID2 is enabled causes the message: collection_store: Failed to access DBM file "/tmp/ip": Permission denied and the rules have no effect.

 

[cPanelMichael]

The same problem as the last few posters. Creating a ModSecurity rule that uses DBM while Mod_RUID2 is enabled causes the message: collection_store: Failed to access DBM file "/tmp/ip": Permission denied and the rules have no effect.

Please see the following posts (there are no new updates):

We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs?

Another way of asking this is - do we effectively have to choose between the two technologies?

Yes, if you're using Mod Security rules that need the DBM functionality.
No, if you're not using those kinds of rules.

In addition:

Hi Manuel, thanks for the feedback.

After briefly looking at the mod_security plugin, I also do not see an easy alternative given mod_security's current implementation. A few possibilities could be (NOTE: this is not an exhaustive list):

World-writable DBM: This requires a modification to mod_security to prevent the file from being forced as 640. It would also be a security violation since this would allow anyone to write to the file and as-such, would not be a good approach.
Per-user DBM (without CageFS): This would also require a modification to mod_security, thus forcing it to write to an alternative directory. Unfortunately, this would have the unintended consequence of writing to a path that is different than what was specified by the rule itself. It could also have other unintended consequences with respect to file/directory creation.
Per-user DBM (with CageFS): CageFS appears to have the functionality necessary to achieve this without any modifications to mod_security. The instructions for this are defined in the CloudLinux documentation, under Per user virtual mount points. Note: I have not tested this approach yet.

 

[Recifier]

Yes, I read the thread as well... which brought me to ask my original question

Is there a case number for this and is there any expected release timeframe?

I just want to be able to keep track against the changelog so I know when to try my rules again.

 

[movielad]

Yes, I've found the OWASP rules do not work properly when mod_ruid2 is enabled alongside the experimental Jailshell with Apache. If I recompile with suPHP and use that instead, no problem at all. It'd be nice to try and get the new Mod Security/OWASP rules functionality working with mod_ruid2.

 

[cPanelMichael]

This has been assigned internal case number 160281. Note that it might not necessarily result in an immediate resolution, but at the very least our documentation will be updated to reflect this incompatibility. There is currently no timeline on a release.

Thank you.

 

[Solokron]

Has anyone made any headway with this issue?

 

[dalem]

Nope and probably never will

 

[manuel.sousa]

Has anyone made any headway with this issue?

There's an issue on modsecurity at:
https://github.com/SpiderLabs/ModSecurity/issues/712

That's probably the first place to watch for while waiting for a fix.

For the meanwhile i've resorted to give world wide permissions on the needed files. This isn't ideal but the lesser evil in my opinion.

 

[Solokron]

It's something, besides setting 1777 on /tmp/global and /tmp/ip, where there any other changes which were necessary?

There's an issue on modsecurity at:
https://github.com/SpiderLabs/ModSecurity/issues/712

That's probably the first place to watch for while waiting for a fix.

For the meanwhile i've resorted to give world wide permissions on the needed files. This isn't ideal but the lesser evil in my opinion.

 

[manuel.sousa]

It's something, besides setting 1777 on /tmp/global and /tmp/ip, where there any other changes which were necessary?

I wouldn't use /tmp but that's bout it. You don't need sticky or execute bit, just make it 0666 or 1666 if you prefer to keep sticky bit.

In my case i'm using /dev/shm/... and i'm creating the directory structure on boot. This gives faster performance since it's running out on memory.

My script is:

#!/bin/sh

mkdir -p /dev/shm/<REPLACEME>
touch /dev/shm/<REPLACEME>/{default_SESSION,global,ip}.{dir,pag}
chown nobody. /dev/shm/<REPLACEME>/*
chmod a+w /dev/shm/<REPLACEME>/*
​

You just need to change <REPLACEME>, and add an entry at crontab to run it @reboot. You also need to add/change SecDataDir at /etc/httpd/conf/modsec2.user.conf.

It's been running ok for months, don't get scared with the sizes of the files because they are sparse and don't really use that much. For instance, checking on one machine, ip.pag gives 64M on ls -l but really uses 840K as shown on ls -s.

From time to time, depending on rules and specially on busy hosts, this ip.pag can cause issues (either on memory or disk) and grows to huge sizes (Gb). When that happens apache status starts having processes "hanging" on Logging for some time (seconds). In reality it's reading lots of 0s from the sparse file.
That's the size reported and not real size, in the above example 64M.

Whenever the size is over 150-200Mb I use: "> ip.dir > ip.pag" on the directory to reset files without needing to remake them. This looses information that's stored but keeps things running smoothly.

Feel free to use/adjust this. As I said it's been working for me for months now and the only issue was when I started having the processes on logging and a EC2 machine run out of iops (was using disk at the time).

 

[Solokron]

Excellent. Great use! I am going to give this a shot now on one of our servers.

Wouldn't placing the script in the init.d for startup be better? That way it is only ran once on boot. Then run a file rotation in cron?

I wouldn't use /tmp but that's bout it. You don't need sticky or execute bit, just make it 0666 or 1666 if you prefer to keep sticky bit.

In my case i'm using /dev/shm/... and i'm creating the directory structure on boot. This gives faster performance since it's running out on memory.

My script is:

#!/bin/sh

mkdir -p /dev/shm/<REPLACEME>
touch /dev/shm/<REPLACEME>/{default_SESSION,global,ip}.{dir,pag}
chown nobody. /dev/shm/<REPLACEME>/*
chmod a+w /dev/shm/<REPLACEME>/*
​

You just need to change <REPLACEME>, and add an entry at crontab to run it @reboot. You also need to add/change SecDataDir at /etc/httpd/conf/modsec2.user.conf.

It's been running ok for months, don't get scared with the sizes of the files because they are sparse and don't really use that much. For instance, checking on one machine, ip.pag gives 64M on ls -l but really uses 840K as shown on ls -s.

From time to time, depending on rules and specially on busy hosts, this ip.pag can cause issues (either on memory or disk) and grows to huge sizes (Gb). When that happens apache status starts having processes "hanging" on Logging for some time (seconds). In reality it's reading lots of 0s from the sparse file.
That's the size reported and not real size, in the above example 64M.

Whenever the size is over 150-200Mb I use: "> ip.dir > ip.pag" on the directory to reset files without needing to remake them. This looses information that's stored but keeps things running smoothly.

Feel free to use/adjust this. As I said it's been working for me for months now and the only issue was when I started having the processes on logging and a EC2 machine run out of iops (was using disk at the time).

 

[manuel.sousa]

Excellent. Great use! I am going to give this a shot now on one of our servers.

Wouldn't placing the script in the init.d for startup be better? That way it is only ran once on boot. Then run a file rotation in cron?

Init.d would probably be better since you can control it to start before apache but I was lazy at the time and it's been a cron entry ever since.

A cron @reboot only runs when the machine boots up, if you do the startup script feel free to reply here and I'll probably change mine.