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.
In my experience, Zend is a greedy, lying company whose software is buggier than a cesspool'ed corpse. Don't believe their salespeople, don't believe their documentation, and don't trust them with your credit card.
"Don't let all your customers munge my data at will" is hardly a whim.
What wrappers are you refering to? Have you tried to convince them to use suexec wrapper? If you can do that, you can make a PHP binary, make it
owned by you. Then make all your php files mode 500 and owned by you.
When did front page come with MySQL or PHP support. God I hope this was a joke.
Funny and I thought Perl == Paid employment recently located
We use the opposite, 1 group for all of our users since we know that each user is "trusted" on the box.
Should apache or any web server software be run as nobody??
Funny and I thought Perl == Paid employment recently located
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.
find $HOME -type d -exec chmod o-r {} \;
While your files will still be readable, the directories that contain them will not be. People can't use "ls" to list your directories this way.
This method doesn't work on all Unix systems. as the setgid bit on directories is interpreted differently. However it will work on MOST Unix systems, Linux and Solaris included
I think its a BSD-ism but can't recall for sure.
Basically, there are no good and easy solutions, but the article does give a few ways to go.
-larsch
For PHP just create a dir, e,g incs, chown it to nobody.nobody then chmod 700 incs. Now put all your sensitive data into a file incs/setup.inc, chown and chmod it as above then in all your other scripts,
include('incs/setup.inc');
Also htaccess the incs dir so that it isn't readable by apache.
If the hosting company didn't know that leave now!
I work at a university where I set up a webserver which provides all employees with the ability to run PHP scripts (with an optional MySQL backend).
In order to avoid the problem that everyone can read everyone else's scripts PHP runs in Safe mode, which confines a script to the dir it's in and the subdirs.
This seems to be working very well.
Regards,
Xenna
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.
Then one of the users can write a CGI that reads the secret files. Since the web server runs the CGI as nobody, then it can read the file just fine.
Under such a setup, if user A wants to read user B's files, user A just has to write a CGI program to read (or copy) user B's files for him. When user A runs the CGI by accessing with HTTP, it will have the permissions it needs to grab user B's files.
-Loopy
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?
Write your scripts in python and then compile them. :-)
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.
What you need to do is to turn PHP Safe Mode on (in the PHP configuration file). Maybe you didn't find this because documentation isn't very clear on the topic. Look for safe mode in php.net, maybe this link is also useful:3 2002.htm
http://www.wrox.com/Consumer/Store/Books/2963/296
Using Safe Mode
Running PHP in safe mode is a great way of making the use of PHP scripts safer, especially if you allow users to develop and run their own PHP scripts. Turning on safe mode will cause PHP to check a number of this before executing functions that could possibly be a security risk.
Include, ReadFile, Fopen, File, Unlink, RmDir, etc.The owner of file to be included must either be the same as the owner of the script running or the directory in which the file resides must be owned by this user. Exec, System, PassThru, etc. Programs to be executed must reside in a special directory (the default is
The problem with this solution is that CGI programs run with the same privileges as the web server itself. In other words, anyone who can write a CGI/PHP/whatever script can view everyone else's file. A wrapper program is needed, not just semi-restrictive permissions settings.
There are 10 kinds of people in the world: those who understand binary, and those who don't.
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.
Enjoy, The CatPieMan
---You're all I need, When the water runs deep, You're all I need, Now I cry my soul to sleep -- Collective Soul, Needs