Slashdot Mirror
Multi-User Websites and Lack of Security?
gh0ul asks: "I've come across a large and seemingly unspoken problem when it comes to webhosting: a multi-user shell service in which any of the hundreds of users can view any file for my website, including my SQL passwords and PHP scripts. I've tried many times talking to the admins but have run out of luck trying to find a way to have my scripts run as they should without anyone being able to just view the source at will or view the passwords for my MySQL databases. Apache runs as nobody, therefore the files have to be readable by nobody, I've heard about wrappers, but the admins refuse to install them.. So how would a normal user go about securing his web files and passwords for this purpose on a heavily populated machine?" When dealing with adminstrators who aren't willing to handle even the basics of web security for their customers, consider moving somewhere else. In the meantime, for Perl users concerned about leaving passwords in scripts, consider using DBIx::Password.
I would be interested in knowing of alternatives for DBIx::Password in other languages, as well. It's a useful idea especially if your scripts find themselves in hostile environments.
Can't they read your MySQL datafiles? Seems like protecting passwords would be moot.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
I'm guessing that you haven't had your morning cup of coffee yet .... :-)
True. The way to deal with this is to not set ExecCGI on the user directories and then use something like cgiwrap, which the original poster's admins won't install.
Have Apache run in a group - for instance www-data - that the users are not members of. When the users' home directories are created, make the group ownership of public_html www-data and the permissions 2750 (o=rwx g=rxs). That 's' in the group permissions is the setgid (set group-id) bit. It means that all files created under public_html will be owned by group www-data. Then you just make sure your files are readable by group and you're set.
Should apache or any web server software be run as nobody??
I wouldn't think so. I run it as http or httpd. Many articles recommend running services as 'nobody'. I can't think of a good reason not to have a specific user account/group for each service.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Normally, you just need to wrap the CGI files, as they contain the nasty code, although, you need to insure that things that might contain executable are disabled [ie, no SSIs, as that'd allow someone to read something, or run something as root.]
For the CGI problem, there's suexec or cgiwrap. [The security reports on cgiwrap are due to the hack job on the Cobolt RAQs. A default install is safe]
Now, for the group thing, you're almost on the right track -- what you can do is to give each user their own group, and put the web server into that group. [You'll need to restart the web server after adding each user if you're using Netscape/iPlanet...I don't know if it's a problem with apache]. You then want to set the permissions such that the group has read access to the files, but that they're not world readable.
[0640 for those of you who like bitmasks] For the CGIs, as they're wrapped, only need to be run as yourself [0700].
I've done both of these before, and I can tell you that they work just fine, however, you have to be careful then about anything that is running as the same user as the webserver. [typically, textpreprocessors, such as PHP or ColdFusion, or any CGIs that are running unwrapped]. ColdFusion is a security nightmare on a multi-user system, as it becomes quickly realized that it was never intended for that sort of use. [Hell, all I need to know is someone's datasource name, and I can do anything to their database that they can...and I can get their datasource name by reading their files...which of course, ColdFusion can do, as it runs as the webserver.]
As for PHP, I have no experience with it, but I'm guessing there's a good chance that it has the same issues as ColdFusion.
Build it, and they will come^Hplain.
Why not try setting up your own machines to run your site. It's not that hard, and I know sites which run off of DSL @ home. One thing many providers seem to lack about 85% of the time is good administration, and when it comes to security your looking at about 95% of insecure companies with all sorts of holes.
Warn the company, that you'll take your business elsewhere should they not comply with your request, then if they don't listen email everyone they host and make them aware of the problem to, and see how fast they'll fix the shit. Sure it may sound fscked up to do something like that, but if it were your company, and someone else knew of major holes wouldn't you be glad someone opened their mouths?
Want Root?
A question to all you Apache developers out there. How feasible is it to run as each user depending on the request? If all the users had a corresponding webuser account and subsiquent group you could set it up as follows:
/~bob the webserver would then su to a webbob user (who is in the webbob group) and would have read access to the dir. This would stop people from having read access of the files as well as stoping them from running CGI scripts to gain access to other's files because all their CGI scripts would run as their user without the need for wrappers. And for those of you who have ACL's you could even go as far as just adding the webbob user to have access which would end the need of having to create separate groups for each webuser.
public_html is owned by bob and the group is webbob permissions are rwxr-x---. When a request is made for
I would imagine that the su would have high overhead for those that simply don't need that kind of features, but if it could be implemented as a module then servers such as this could add the feature as needed.
That doesn't help much, though.
It's trivial to know what the directory name his web files are in, and since it only takes a visit to his webpage to find out the filenames for his PHP sourcefiles. A simple 'cat' and you've got the database passwords.
Honestly, I'm not sure what you can do on a true multiuser system, especially with PHP. You could certainly try and obscure things through some evil hacks and kludges but you can always work around it.
The submitter said it himself: since apache runs as nobody, any files it accesses need to be readable by nobody. I've never found anything that can get around that fact...
My solution? Don't run any of my websites on machines that have users I don't trust.
While this may or may not help (and if it does help, only for PHP developers) you might want to take a look at the Zend Encoder Unlimited. It is supposed to encode php scripts so that people can't just read them. Not sure if the server needs to configure anything or what have you, but it's worth a shot.