Extra security with read only access


#1

From time to time, I think about the security of my web site…

PHP-CGI is more secure than the Apache module beacuse you don’t need to leave your scripts world-readable.

Then Will said will PHP-CGI is a bit of a nightmare from a security point of view. I assume that’s because scripts runs as your user, giving it full read-write access to your entire home directory.

Then SourceForge decided to mount web directories read-only, in the name of security.

So I got this idea into my head of creating a new user in the same group as me, and making my files and directories read-only to the group. In other words, the web server would be able to run the CGI scripts, but wouldn’t be able to write or delete any files in my home directory.

(You can accomplish this to some extent by remapping a subdirectory to a different user, but you can’t do that for your entire site. The KB says something about breaking scripts, but it seemed okay to me, as long as the script is group-readable. But maybe I’m forgetting something.)

Would this be worthwhile? (i.e. does it do much good?)

Is there an easy way to do it?

Is it a completely stupid idea?

I figured someone who knows more about this than me might have some input. :slight_smile:


#2

Our system will not allow a script owned by another user to run under your domain. The apache ‘suexec’ functionally prohibits that for security reasons. You script must be owned by your cgi user (whichever user the domain is configured to run under) and must not be group writable, and the same for the directory it lives in. I think that will prevent you from doing what you’re suggesting.

Making the filesystem read-only does prevent a lot of the common server exploits since they typically need to be able to write something to the drive to actually accomplish anything so it is a good idea if you have a controlled system like the SourceForge people do and you are very worried about security. It’s not possible in most server setups, though, especially shared hosting setups like ours.

Also note that scripts running are not confined to only access files within the webserver’s document root. In the case of PHP they can access any files within the home directory of the user the domain is running under.

Anyway, it’s a good idea in theory but it won’t work in our shared hosting environment.

  • Dallas
  • DreamHost Head Honcho/Founder

#3

Thanks for your reply. :slight_smile:

Right, that’s the impression I got from the web panel… but the weird thing is, scripts seem to work fine no matter who owns them. I must be misunderstanding something.

Here’s the test I did:

Username: me
Domain: example.com in /home/me/example.com

Second user: other
Remapped http://example.com/test to /home/other/example.com/test

And two test scripts:
/home/other/example.com/test/index.php
/home/other/example.com/test/test.pl

Owned by “other”, everything chmod go-w. (Read-only to user “me.”)

Both ran fine, as username “me”.

Isn’t that what suexec should prevent?

Maybe I need to think about this more. :slight_smile: Obviously this test is a bit different from just changing the username my site runs as.


#4

Hmm, you’re right. It looks like our configuration changed since I last checked. We now have set suexec to allow scripts to execute as long as they are set to your group.

That does make it easier to do the more secure setup you were describing. Note that any script running on the system as your user has the same privileges as you do when you are logged into the shell so a crafty hacker could look in /home/$USER and try to write files there. That would require them to be a little bit smarter than your average hacker so it may still be worth the effort, though!

  • Dallas
  • DreamHost Head Honcho/Founder

#5

Right, so directory re-map is only a partial solution. I figured the way to do it is create a dummy CGI user, and leave DocumentRoot pointing at the main user’s account. The dummy user’s home directory would be empty–he could even have a 0-1 MB quota. He wouldn’t be able to write anywhere worthwhile.

So the only technical barrier I can think of is that the web panel forces you to put DocumentRoot in the CGI user’s home directory. (That certainly makes sense under the old suexec setup you described.)

Just trying to think of any little wrinkles… Some scripts might need to write files, but as long as any writable directories are outside of the public web space (or in a directory with CGI/SSI disabled), it should be fine.

Anyway, I’m not sure that there’s a demand for that capability, but it’s fun to think about security issues. :slight_smile:


#6

It’s now a suggestion: :slight_smile:

“Allow CGI user to be different from web dir owner.” (2 credits)

I wonder if anyone will know what that means. :slight_smile:


#7

[quote]It’s now a suggestion: :slight_smile:

“Allow CGI user to be different from web dir owner.” (2 credits)[/quote]
Voted for it l-) We now have 40 voting credits :slight_smile:

happylittlethings.com


#8

We actually did allow this for several years until we changed it at some point. We noticed that hardly anyone ever used it correctly and it confused way more people than it helped.

Anyway, I believe this can still be set up manually by us though changes made from the web panel after that would probably cause somewhat unpredictable behavior.

  • Dallas
  • DreamHost Head Honcho/Founder