[HOWTO] mod_ruid2

defomaz said:

@skaag

if you use mod_php + mod_ruid2
you should use .htaccess to change php variable per user

Click to expand...

You can also use the 'Custom HTTPd' option in DirectAdmin controlpanel for the admin.

Just found this out. For the webapps to run under webapps under the domain.tld/roundcube you need to add in /etc/httpd/conf/httpd.conf

In the



so you have it like this


Makes sense, as you can see this was already done for suPHP.

Arieh said:

Just found this out. For the webapps to run under webapps under the domain.tld/roundcube you need to add in /etc/httpd/conf/httpd.conf

In the

Code:

<Directory "/var/www/html">

Code:

RUidGid webapps webapps

so you have it like this

Code:

<Directory "/var/www/html">
    Options -Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
   <IfModule mod_suphp.c>
        suPHP_Engine On
        suPHP_UserGroup webapps webapps
        SetEnv PHP_INI_SCAN_DIR
   </IfModule>
   RUidGid webapps webapps
</Directory>

Makes sense, as you can see this was already done for suPHP.

Click to expand...

Thx! i will do this also!
Yep this works perfecT! thx

I always get the following error:

Permission denied on /

Then in the error log is:

[Thu Jul 21 18:11:23 2011] [crit] [client 71.202.43.154] (13)Permission denied: /home/admin/domains/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

The error presists across all domains and users...

Does anyone have a proper guide from switching from suphp to ruid2?

The first post doesnt help?

Did u comment SuexecUserGroup |USER| |GROUP| in http template?

The specific file is owned by the user that own the domain?

Webpaged are online or you have problem on see website? Or is just this voice in the log?

Regards

All pages come up with "Permission denied on /"

There was no suexec stuff in my template and I disabled suphp and removed loadmodule line for suphp.

Still not sure whats going on...I will have to try some things in the middle of the night to see if I can figure out why its not working. I wonder if it has something to do with the secure access group.

No, is working correctly with me, usually when i got a permission error is cause the files are not 644 and the folders are not 755.

What apache log say?

I can check your box if you want/need.

Regards

This is one gorgeous thread. It is so totally logical to have MOD_RUID2 be part of the PHP CLI custom build install. It has the security advantages of suexec and more with none of the drawbacks. It paves the way for installing WebDAV right along with it. WOW! You don't run across long hanging fruit like that very often.

Hello,

Having the ability to run php with CLI (more efficient than suPhp), but running as the User has clear advantages (write permissions) and also lets the secure_access_group option make home directories be more secure (without needing open_basedir, but keep it on). The only catch is the fact that apache would be running as root (don't quote me on this, I'd need to do some homework), but if there are any exploits in apache, ssl or a module, that would be a wide open door for full access to your box. I'm sure that they've taken as many security precautions as they can, but that fact still worries me slightly. (again, I'll have to read up on it to see if this worry is substantiated). If not, then we can look into it for a new project as a custombuild install option.

John

Hi John,

i know you sayd dont quote but.. afaik.. mod_ruid make apache run just as is, user/grou apache ... at least that is what i see from my http.conf (using mod_ruid2)



I can totally say that security has been incresed when ive started use mod_ruid2. (actually i had nothing before cause didnt want suphp) but, is working very well and user apache process are just under the user who started it.

I would suggest to implement that, and, if you need i can write you an email with the steps i use and my confs files for a check.

Regards

DirectAdmin Support said:

Hello,

Having the ability to run php with CLI (more efficient than suPhp), but running as the User has clear advantages (write permissions) and also lets the secure_access_group option make home directories be more secure (without needing open_basedir, but keep it on). The only catch is the fact that apache would be running as root (don't quote me on this, I'd need to do some homework), but if there are any exploits in apache, ssl or a module, that would be a wide open door for full access to your box. I'm sure that they've taken as many security precautions as they can, but that fact still worries me slightly. (again, I'll have to read up on it to see if this worry is substantiated). If not, then we can look into it for a new project as a custombuild install option.

John

Click to expand...

As I read, only exploit to SSL module can lead to root access, but still it can be abused. Anyhow, I'd like to see that as an option!

I'd think it would be wise to indeed dive into this security issue. If you read the readme of mod_ruid2 it says something about this. (by the way theres a new version .4, start post contains .3).

Anyway to qoute the README:

there are some security issues, for instance if attacker successfully exploits the httpd process,
he can set effective capabilities and setuid to root. i recommend to use some security patch in kernel (grsec),
or something..

Click to expand...

I've ran some test and talked about it in this thread, and if you don't have the php function dl disabled, you can set the uid to root using a comiled .so. See the topic for more information.

I don't consider myself an experienced security expert; so I think someone who is should really be consulted (or maybe John is), before rolling this out to everyone.

DirectAdmin Support said:

"...The only catch is the fact that apache would be running as root...if there are any exploits in apache, ssl or a module, that would be a wide open door for full access to your box.

Click to expand...

I've read that, but I'm not sure how that is so different from the current situation?

DirectAdmin Support said:

"...running as the User has clear advantages (write permissions) and also lets the secure_access_group option make home directories be more secure

Click to expand...

I agree. I like it that suEXEC covers CGI/SSI files, but for the other files, neither the current CLI nor suEXEC method covers those. Currently, we need to coordinate two incompatible security matrixes. And how difficult, is it to detect which user web applications are running on a site, and know where to check for improperly secured security/configuration/data files? With mod_ruid, security would be far more straightforward. That itself is a big security advantage. Not having to deal with two incompatible security matrixes also enables technologies such as WebDAV, and more.

DirectAdmin Support said:

,,,(without needing open_basedir, but keep it on)

Click to expand...

I agree wholeheartedly. Even if you could be sure there would never be a module vulnerability, with thousands of directories, how could one possibly manage security, or locate the source of an exploit? open_basedir clearly documents where access is possible.

Other:
The current dilemma is choosing between performance and compatibility of CLI, or security with suexec. mod_ruid solves both, and more.

For those who don't understand the extra security risk by using this mod;

mod_ruid2 uses POSIX capabilities to swap uids of processes. With the intended use only normal users will get swapped. But because scripts are executed; php/cgi - theres a problem. These scripts can hijack/access the uid swapping stuff because of mod_ruid2. So with an evil script, and not secured, you can swap to root.

It would be a good idea for people to read the README of the software you install. Apparently no one (except John mentioned it) in this thread knows about this or cares about it. It would be comforting if someone knew about this issue and whether its a true risk, and if theres something you can do about it. I've made an attempt to find it out as I pointed out in my previous post, but there has been nobody saying something about it, unfortunately.

Arieh said:

For those who don't understand the extra security risk by using this mod...It would be comforting if someone knew about this issue and whether its a true risk, and if theres something you can do about it. I've made an attempt to find it out as I pointed out in my previous post, but there has been nobody saying something about it, unfortunately.

Click to expand...

I noticed during my Googling that mod_ruid appears to be an option with Plesk/Parallels. That might be a good place to learn how they handle these issues.

Arieh said:

With the intended use only normal users will get swapped. But because scripts are executed; php/cgi - theres a problem. These scripts can hijack/access the uid swapping stuff because of mod_ruid2. So with an evil script, and not secured, you can swap to root.

Click to expand...

From the README:

there are some security issues, for instance if attacker successfully exploits the httpd process, he can set effective capabilities and setuid to root. i recommend to use some security patch in kernel (grsec),

Click to expand...

One cannot determine from that if the risks greater or less than suEXEC, which is a wrapper that does the same thing. One would THINK there would be little point in developing mod_ruid2 if it were easy to exploit, which is why the odds are that it would be worth the time to investigate. One might even counter by saying that logically mod_ruid2 might be less susceptible to exploit because it has the potential to run earlier because the file extension is not a consideration, and also because the file extension type is not a consideration. One might conclude from these two factors that it would be logical that mod_ruid2 would have a smaller attack surface.

I noticed from one of the threads you referenced where you attempted to change users from within a script but where unsuccessful. PHP POSIX is installed on all of our DA machines without mod_ruid2 being installed.

I agree that as with anything that has to do with computers, if you don't do your homework, things can go very wrong.

Things that I do know:

1)

I've read that, but I'm not sure how that is so different from the current situation?

Click to expand...

If there is an exploit, they'd be in, running as apache. If there is an exploit with mod_ruid2, they'll be running as root... and there isn't much to slow that case down.

2) Comparing mod_ruid2 vs suexec, I have personally gone through the suexec.c file, one line at a time (when we had implemented the chroot jaling system). The difference with suexec is that the process runs as apache right up until the last moment, well after all requests have been made and things are all ready to go. Only then does the suexec binary get called, with all of it's internal checks for uid values, path values etc... So the "exploit" part would be have been done prior, during the "apache" time.

With ruid, I'm not 100% sure when the change to the User happens, but it would have to happen after the request has been made... so after things are parsed, etc... During the parsing, reading, and processing, the process would be running as root. The most likely place for exploits is at connction time (if it's an ssl issue) or parsing, if it's a buffer overrun, etc... and that's really the issue in my mind. Again, I have not gone through the mod_ruid2 code like I have with suexec, so cannot say for sure where it stands.... but if the author states these exact issues, eg: "if attacker successfully exploits the httpd process, he can set effective capabilities and setuid to root", then my thoughts are likely substantiated. It's just one less layer of security... as I'm sure mod_ruid2 has done many checks, and it, in itself is probably secure, but missing that extra layer would concern me. From what I understand, the process (after an exploit) would only need to make a call to seteuid(0) to get root. (apache may run with euid as apache, but the true uid is likely root/0, hence seteuid works to get root, from non-root).

Anyway, as long as people are aware of this potential issue, they can ensure they keep everything completely up to date, the chances of risk would go down. If we implement it, it wouldn't likely be default setting, but having it as a custombuild options.conf setting sounds feasable.

John

I appreciate you taking the time to explain your point of view. I agree that it is logical that the UID change would happen early. My point of view is that logically, the code would drop from root to the user level, less than apache, almost immediately. Your point of view is that the earlier it runs, the more vulnerable it would be to buffer overruns. I would have to agree with that too. I would be interested to learn what you discover.

Thanks,
Jack

Hi

Each time I rebuild PHP, I have a problem (I want to install imap, as to use function imap_open() ).


So I run :

Then new error message :

Then I rebuild mod_ruid2

It works again... but I have no imap !

So, is it possible to have IMAP with mod_ruid ? I don't know why I can't install it.

I use this to install imap :

Hi

I try a new method to add imap

http://www.directadmin.com/imap.txt
then : http://help.directadmin.com/item.php?id=252

And no problem after ./build php

And imap is available, with mod_ruid2.
I don't know what was wrong in the other method.

@pppplus the different is that the help guide created a 'custom' directory instead of using the current 'configure' directory.

Configure directory will be overwritten each build update/update_data.
custom wont be touched, so your changes will be safe.