Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
News

Multi-User Websites and Lack of Security? 27

Posted by Cliff from the please-tell-me-this-isn't-normal-for-webhosting dept.
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.
This discussion has been archived. No new comments can be posted.

Multi-User Websites and Lack of Security? More

Multi-User Websites and Lack of Security?

Comments Filter:

  • Re:tried Zend? (Score:1)

    by Anonymous Coward
    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.

  • Re:Annoys me (Score:1)

    by Anonymous Coward
    "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.
  • Seems like a relatively small task to setup a user for the web server, then a group for each web site, or user account, then place the web server user in each of those groups as that would allow the web server to read the files. Then set the ownership on those files to the user/group of the web site owner.

    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??

  • Can't they read your MySQL datafiles? Seems like protecting passwords would be moot.
  • the AC was being sarcastic about Front Pages security.

    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 [unixtools.org], which the original poster's admins won't install.

  • setgid (Score:3)

    by matthewg ( 6374 ) <matthewg@zevils.com> on Monday June 18, 2001 @09:58AM (#143726) Homepage
    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.

  • in the 'normal' setup, the actual files containing the data for MySQL databases are readable only by root or the mysql user. In order for *anyone* to get at the database, they have to go through the MySQL daemon (which works, as it is usually running as user mysql)
    --
    // mlc, user 16290
  • I found a document on the "mod_perl site [apache.org]" called "mod_perl for ISPs - mod_perl and Virtual Hosts [apache.org]" which addresses exactly the problem of having multiple scripting users on the server, securely.

    Basically, there are no good and easy solutions, but the article does give a few ways to go.

  • 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.

  • 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.
  • 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?

  • Python (Score:1)

    by lw54 ( 73409 )
    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:

    public_html is owned by bob and the group is webbob permissions are rwxr-x---. When a request is made for /~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.

    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:
    http://www.wrox.com/Consumer/Store/Books/2963/2963 2002.htm [wrox.com]

    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 /usr/local/php/bin). You can set this value before compiling PHP with the --with-exec-dir option. Mysql_Connect This function takes an optional username to use to connect to an MySQL database. When in safe mode, this username must either be the username of the owner of the current file being parsed, or the name of the httpd user (usually nobody). HTTP Authentication The numerical user id of the owner of the script containing the HTTP Authentication code will be prepended to the authentication realm. This is to prevent someone from writing a password.

  • Re:chmod (Score:3)

    by Echo|Fox ( 156022 ) <forums&discordia,ca> on Monday June 18, 2001 @07:49AM (#143741)
    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.
  • 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.
  • 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 [zend.com]. 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.
  • I just ran a test on my machine. If you chmod everything to 711, other users cannot read your files and, the web server can still execute all perl scripts (haven't tried php or python), and, they cannot be read or executed by other users, at least, it works fine on my SuSE 7.0 .

    Enjoy, The CatPieMan

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close