Security of SuExec under Virtualmin

Virtualmin
1

Hi everybody,

In this post, I would like to discuss concerns about SuExec from the point of view of security.

I am well aware that SuExec was invented to provided more security in a shared hosting environment. However, I have concerns about how Virtualmin uses this tool (or maybe about the very nature of SuExec). The public_html folder is owned by the virtual server owner (say “admin”). The group would also be “admin” and the permissions are 0750. So far good.

Now, let’s say I have a complex application and I was careless enough to not check user input thoroughly. Here is my complex application:

/home/testserver/public_html/test1.php: (Owner: “admin”, Group: “admin”, Permissions: 0640)

<?php file_put_contents("/home/testserver/public_html/test2.php", '<?php unlink("test3.php"); ?>');

?>

/home/testserver/public_html/test3.php: (Owner: “admin”, Group: “admin”, Permissions: 0640)

<?php echo 'Test file'; ?>

So, the “hacker” will access http://www.testserver.com/test1.php. Since test1.php is executed using “admin” (because of SuExec), test2.php will be created in the public_html folder. The owner of this file will be “admin.” Then the hacker will go to http://www.testserver.com/test2.php, and my test3.php will be deleted. I have actually tested this situation.

This is, of course, an extremely naive and simplistic scenario. However, to me, the mere possibility of modifying the structure of the virtual server using publicly-accessible scripts represents a disadvantage. It seems that this is possible due to the fact that by default, the owner of the public_html folder is the same as the user used to execute PHP scripts, and apparently SuExec requires this.

This might not be a problem if programmers use good security measures in their scripts. May be there is a good reason to have this setup. Here are two solutions that I have thought of so far:

  1. Don’t use SuExec at all: if the scripts are run as “apache,” then they won’t be able to alter the structure of the virtual server unless you explicitly create a folder where “apache” can write files. Of course, this means that other virtual server owners can write to this folder.

  2. Leave SuExec alone, but instead of using “admin” as the owner of public_html, create another user (admin-webuser) that will be the owner of this folder. The group for this folder can be left as “admin.” This way, admin-webuser can upload and change files to public_html, and PHP scripts can be executed using SuExec. However, I think this still leaves other parts of the virtual server vulnerable (/home/tcs/*).

I would love to hear opinions. I am a big fan of Virtualmin (I am using Virtualmin 3.83.gpl), and it would be great to understand it in greater detail.

Thank you for reading this long post!

2

Howdy,

Yeah, it seems as if there’s upsides and downsides to any way of doing things :slight_smile:

It is indeed true that if a PHP script is running as the Virtual Server owner, that it would then have rights to modify the contents of those files and directories.

So, other users are protected from intrusions, since one user can’t see the files of another; but it also means an intruder can modify the users files.

On the other hand, if you use mod_php – the script runs as Apache, meaning it can’t modify your users files (so long as they aren’t world writable), but suddenly, one intrusion means that intruder can see (but not modify) everyone’s web content on your server – since the intruder would at that point have the same rights as Apache does.

Most folks feel the second issue is the worse of the two security issues. If I were on a web hosting provider, and was told that a security issue in another users web app meant all my data could be stolen, I wouldn’t be happy about that :slight_smile:

As far as your one comment here goes –

It seems that this is possible due to the fact that by default, the owner of the public_html folder is the same as the user used to execute PHP scripts, and apparently SuExec requires this.

Remember that the script suexec is executing in this case isn’t the .php script, it’s the ~/cgi-bin/php5.cgi script. The .php script is just a parameter being passed into php5.cgi. So, suexec would care about the ownership of php5.cgi and cgi-b in, and not the php script. If you want to change the ownership of public_html, I don’t believe that would be a problem from the standpoint of suexec.

Personally, I’d prefer the problems of running suexec as the Virtual Server owner – and just being diligent about keeping software apps up to date, as well as keeping good backups. If there ever is an intrusion, it’s just a matter of determining how they broke in, restoring last night’s Virtual Server backup, and plugging the hole.

Not everyone is as comfortable with that strategy, and doing things another way may be best for some folks. I’m most curious what you end up doing for your server – once you decide on a setup, let us know what direction you choose :slight_smile:

-Eric

3

Eric,

Thank you for your wonderful reply. Let me make sure I understood what you are saying about mod_php:

In a default Virtualmin setup, the user “apache” belongs to two groups “apache” and “admin” (remember that for the purposes of this topic, “admin” is the user and group of the virtual server’s owner). Now, suppose I use mod_php instead of FCGI. It is possible to write a script such as:

/home/testserver/public_html/test1.php: (Owner: “admin”, Group: “admin”, Permissions: 0640)

<?php echo file_get_contents('/home/testserver/public_html/test2.php'); ?>

/home/testserver/public_html/test2.php: (Owner: “admin”, Group: “admin”, Permissions: 0640)

<?php // This file could contain MySQL passwords ?>

Accessing http://www.testserver.com/test1.php would show the MySQL passwords!

However, it seems that unless I deliberately write a script like this, no intrusion (except SSH perhaps) would allow the world to see the entire web contents of the virtual server. I might be wrong. Could you clarify that for me?

Now, I have been thinking of another setup that might solve the SuExec problem. First, thank you for clarifying this:

Remember that the script suexec is executing in this case isn’t the .php script, it’s the ~/cgi-bin/php5.cgi script. The .php script is just a parameter being passed into php5.cgi. So, suexec would care about the ownership of php5.cgi and cgi-b in, and not the php script.

I created a user named “admin-suexec” for this particular virtual server. Then, I went to Services > Configure Website > User and Group and changed the user to “admin-suexec” and left the group as “admin.” Then I changed the owner of /home/testserver/fcgi-bin and /home/testserver/fcgi-bin/php5.fcgi to “admin-suexec.” The owner and group of public_html stayed the same (admin:admin). When test1.php (from my original post) tried to create test2.php, it got an error: “Permission denied.” This is what I wanted! Since PHP files are “executed” as “admin-suexec,” they cannot alter the contents of the virtual server unless I assign appropriate permissions and/or ownership to a folder.

Do you think this “hack” is a little dirty? This is a test and I am undecided whether I should do that in my production server.

Thank you!

4

Well, the problem you have is that in order for mod_php to work (in any environment, not just a Virtualmin one), the Apache user must be able to read all the web content for every user. There’s obvious drawbacks to that :slight_smile: But that’s how mod_php works, by running as the Apache user.

Check out this blog post here, it’s a few years old, but touches on some of the issues you’re talking about:

http://boodebr.org/main/node/7

Whether they break in via mod_php, with suexec running as your Virtual Server owner, or suexec running as another user – the potential for stealing data (including your MySQL password) exists. The option you were considering, running suexec as a user other than the Virtual Server owner – that makes certain things a little harder… but depending on what kind of security issue you’re dealing with, someone could certainly still end up with your database password.

I personally wouldn’t suggest using mod_php on your server unless you need it, or if all the users and web apps on your server are trusted. But as far as the other two options go –

Do you think this “hack” is a little dirty? This is a test and I am undecided whether I should do that in my production server.

Well, for any server, the admin of said server has to weigh their security needs, and do what’s right for them :slight_smile:

Personally, I’m okay with the idea that an intruder could access files as the Virtual Server owner. I handle that by keeping apps up to data, running tools such as mod_security (which attempts to pro-actively prevent intrusions), and having good backups.

That’s not an acceptable solution for everyone, and if you don’t like that idea, what you described could certainly work. I’d suggest doing some testing with the apps you’ll be using before it goes live
just to make sure nothing unusual comes up.

-Eric

5

I will probably stick with SuExec using the virtual server’s owner.

The reason all of my concerns originated was because of PhpMyAdmin. I downloaded the tar.gz file from their site and proceeded to copy the files to the public_html folder and configure it. It worked very smoothly, but I was not sure about the permissions. They mention this in their installation instructions:

All your phpMyAdmin files should be chown -R phpmy.apache, where phpmy is a user whose password is only known to you, and apache is the group under which Apache runs.

Of course, this is irrelevant in a SuExec environment. I believe it is okay to chown all phpMyAdmin files to admin:admin (the owner of the virtual server), am I correct?

In a more general sense, would it be correct to say that the permissions for web content (including phpMyAdmin) should be 0640 for files (0750 for folders) chowned to admin:admin? This way, non-PHP files can be read by “apache” and PHP files can be executed by SuExec.

6

In a more general sense, would it be correct to say that the permissions for web content (including phpMyAdmin) should be 0640 for files (0750 for folders) chowned to admin:admin? This way, non-PHP files can be read by “apache” and PHP files can be executed by SuExec.

Those permissions should be fine… but a quick and easy way to prevent other users from gaining access to your files would be to just make sure that /home/USERNAME is set to 0700, or perhaps 0750.

So long as no one can gain access to the /home/USERNAME directory, the permissions of the files underneath it wouldn’t matter so much.

-Eric

7

Accessing http://www.testserver.com/test1.php would show the MySQL passwords!

However, it seems that unless I deliberately write a script like this, no intrusion (except SSH perhaps) would allow the world to see the entire web contents of the virtual server. I might be wrong. Could you clarify that for me?

That is not the issue (with suexec, it’s the same).
The issue here is that when php is run as user www-run (or sth like that), your test.php could read the files of other users (file_get_contents(’/home/someotheruser/public_html/secret-stuff.php’)

So, without suexec

  • you have to trust all users on the system (almost impossible for shared hosting)
  • a breakin into ONE domain puts ALL domains at risk
8

0700 would be not good: you would loose the ability of serving static files.
suexec is only used for execution of cgi-skripts, static files (*.html, *.js, *.css, *.gif etc…) are served by apache as user www-data (or “apache”, “www-run”, or whatever you have configured or is default on your distribution).
This user is put into all the groups of the virtual servers. (just enter “id www-data” via ssh…)

9

Since all files in virtual server home folders are by default user:user 750, then it shouldn’t actually matter whether the permissions are 750 or 700?