Securing a multi-user web hosting machine

[Buddha Bart]

I've got two projects that are going to need something along these lines, and I'm curious what others of you have seen or done to address this problem.

Because the apache user (nobody, www-data, whatever) needs read access to everyones website directories (~/public_html), they must be set world-readable. Which means anyone on the system can run a php or perl script to read files in other peoples directories/sites. The problem with this becomes database username/passwords. If anyone can read them then anyone can mess with each others db's.

Now I know with PHP I can solve most of this with safe mode, openbasdir, and a large list of restricted functions, but that still doesn't solve Perl for me.

Plus, here's a doozy... I really want to give users shell access.

So, PHP, Perl, and Shell.... yet not allow people to look in others directories, all the while allowing apache to do so. Impossible? or a challenge

bart

 

[Soybomb]

How about an example of an application or something this will present a problem for? If its in the web directory it should be world readable since its effectively published. If its in their home directory but not the web dir they need to learn permissions to keep others from reading it. I wouldn't worry about it too much. If they're storing passwords as cleartext in files that could be a problem, but thats what hashed passwords are for

The only other thing I could think of would be setting permissions on a file/directory to 650 and setting the group to the apache group. Apache could read, other system users couldn't. Not really much of a handy solution to anything though.

Anyway I'm curious to see what people who actually give shell people access think since this isn't something I ever have to consider.

 

[Barnaby W. Füi]

How about an example of an application or something this will present a problem for? If its in the web directory it should be world readable since its effectively published. If its in their home directory but not the web dir they need to learn permissions to keep others from reading it. I wouldn't worry about it too much. If they're storing passwords as cleartext in files that could be a problem, but thats what hashed passwords are for

The only other thing I could think of would be setting permissions on a file/directory to 650 and setting the group to the apache group. Apache could read, other system users couldn't. Not really much of a handy solution to anything though.

The problem is that, even if they aren't readable to other users, they *have* to be readable to the www user, and if they're readable to the www user, then they're readable from other people's scripts too, and thus, they are readable to those users. Password hashes don't matter much, they won't get the actual text of your password, but they'll still get access to your database.

Anyway I'm curious to see what people who actually give shell people access think since this isn't something I ever have to consider.

I don't give shell access to anyone that I don't know and trust in real life, which is _very_ few people (about one, most of the time). People I trust so much that I don't even need to hide my database/etc passwords from. I think I would be too paranoid if I gave people shell access that I trusted less than that.

 

[Haden]

XFS ACL's could help, but I don't know are they ready for use right now.
Also getfacl/setfacl utils seems to be able to set multiple permisions (like granting any user(s) read access etc.)

 

[Barnaby W. Füi]

I don't see how ACLs would even help. The same user (www-whatever) is accessing them.

 

[Nothinman]

Bing's right, nevermind.

 

[Haden]

Originally posted by: BingBongWongFooey
I don't see how ACLs would even help. The same user (www-whatever) is accessing them.

True, I didn't read post carefully...

 

[Barnaby W. Füi]

(It took me a few re-reads to totally understand it too )

 

[Buddha Bart]

Sorry if I didn't word it as cleanly as possible. I was trying to pre-emptivly head off most of the "try this" things that I already thought of.

My brain's really stuck on this one... my only thought would be if each persons virtual host had their own apache process (like i've heard 2 does) that ran as their user. Then nobody would need to set anything world-readable.

Also, if anyone here is familiar with php's safemode. Whats to stop me from exec()'ing a bash script i've made that reads the other users files/directory? I could just blacklist exec(), but I'd rather not start down that path as I imagine the list of functions to blacklist would grow exponentially, and generally make life a pain in the ass for the users.

Is there a way to chroot a shell-user to their home directory, while still giving them the ability to execute the basic things they'd need in /bin (and all its cousin directories)?

 

[Barnaby W. Füi]

I would also agree that php's safe mode and disabling certain functions are a painful way to go about it (and what about perl, anyways?)

Hmm, would kerberos be of any use in this situation (I don't know much about it) ?

 

[cleverhandle]

Interesting problem...

Originally posted by: BingBongWongFooey
Hmm, would kerberos be of any use in this situation (I don't know much about it) ?

I don't think so. Kerberos would authenticate external users to access certain pages via the Apache process. While you could move password and access db's off the web server, whatever content is being served - the content being protected by those passwords - would still be readable by perl/php scripts, which can access that content directly, thus skirting Apache's authentication.

Originally posted by: Buddha Bart
...my only thought would be if each persons virtual host had their own apache process (like i've heard 2 does) that ran as their user. Then nobody would need to set anything world-readable.

But I think this is possible, in a somewhat ugly way. Give each person their own apache parent process, each one binding to a separate port and running as a separate user. Then set up a master process listening on port 80 with permanent redirects to the appropriate port for each person's webspace. You could probably even keep the overall namespace consistent. Of course, this is not resource efficient, and process and configuration management becomes a little hairy. But it's mostly transparent to both the users and the page viewers, and shouldn't be complicated by shell access. If you take the time to set up good control scripts and templates for config files, it would be quite painless to maintain once set up, unlike an ongoing battle trying to control perl and php directly.