Slashdot Mirror
Isolated Apache Virtual Hosts?
An anonymous reader writes: "Anyone ever had to set up virtual hosting on a server that allows CGI execution, etc? This seems to be simple, until you want to keep users out of each other's data. The Apache config seems straightforward enough, but I still haven't figured out the best way to set up the user groups on the box to keep them trapped in their areas and out of each other's business. I thought I could put each user in his own group to block prying eyes on the system side, then add the web user to all the other user's groups allowing him to get to their files, using suexec to prevent one user from using the web server to look at another user's files. This works well, but there seems to be a limit on the number of secondary groups a user can be a member of. So, the web user hits a wall at roughly 16 "customers" or user accounts. Any suggestions on how to improve on this and get beyond the limit? Or is there a better way to approach this than the group/suexec thing? Any pointers to online resources dealing with this type of config would be great..."
Let each person's home directory be their website, then just point the Apache virtual servers to the users' respective homes. Remember, of course, to add the Apache user itself to each user's personal "group" so it can see their stuff. :)
Super easy, I've been doing it for years. ('Course now somebody's going to point out some huge security flaw in this arrangement and I'll be kicking myself from here to breakfast...
Might be worth looking into whether or not Apache can handle chrott with virtual hosting.
It should be fine to have each user be the owner of his files and the directory, and set the group to the webserver's group... If you set the SGID bit on the directory (in Linux, at least), all files are created with the group being the same as the directory. Shouldn't be any hassles with group memberships, etc.
If you had Apache feeding the requests to Zope (or any other Content Management System, really), then you could get much finer-grained control on permissions.
New title for Ask Slashdot
Read The Fucking Google
Putting them on physically separate machines is safest (and very expensive), but if the VM implementations are any good, then using VM servers might be a possible solution (not so expensive).
While in theory you could give each user their own webserver in a single unix/linux machine, as far as I'm concerned once a user has an account on a typical Unix machine they can eventually get root if they want, so you might as well give them their own machine (virtual or otherwise). You can secure each machine reasonably for them at the start but if they want to do silly things hey it's their machine.
And I figure if the VM implementations are good, you should be able to migrate a user to his/her own physical machine reasonably easily for a higher priced "Gold" service. And more importantly back down again.
And a platinum service could be one VM on many physical servers!
- Create a webusers group and make all hosting clients members of it
- Set permissions of web files to 604 or 705
- Set ownership as follows:
- user: the file's owner
- group: webusers
- The web server should run under a group other than webusers
Set up like this each user can access their files (they have read/write/execute permission on them), but not those of other group members. The web server still be able to access them since it is not part of the webusers group and thus falls under the 'other' set of permissions. It is important to restrict access to the server to members of the webuses group and to administrators - there should be no regular users on the machine who are not in the webusers group. A server set up this way should do want you are trying to do.Accept Eris as your Fnord and personally sate her
If you make them use something like PHP, you can easily make them stay at their side of the server...
The easiest thing by far (if you have the money and no itch) is to become a reseller at Verio. Their servers are set up to handle just this kind of thing, and they do it extremely well. I have been running a virtual server with them for years, with "virtual" root access on the same box as numerous others - no problems.
A friend of mine told me that the vserver software they use (currently under freebsd) is open, but I couldn't find any mention of that anywhere. Supposedly there is a similar vserver project going on under RedHat.
Or you might want to ask the maintainer of PVHost if he will implement what you need. The project is defined as:
"PVHost is an ISP/poweruser tool that lets admins easily create new virtual web servers using Apache, PHP, mod_auth_mysql, and custom ftpd. It supports PHP, FTP and FrontPage rights control, etc. Custom ftpd allows creation of ftp accounts without the need"
Hurra for Knark!
At the ISP I work for, we have been using the Roxen web server since 1997-98 and it has always had the "Run scripts as" option in the CGI module located in the modules for each site. It defaults to 'nobody' but if the web server is running as root, you can specify any username in this box. It is dificult to get PHP running on Roxen, but for everything else it works great. Documentation located at: http://docs.roxen.com
Mandatory Access Control in HP Secure OS Software for Linux can solve the problem. Part of it is proprietary, but then again, so is the VM in IBM zSeries (S/390). The kernel modifications and kernel modules are licensed under the GPL, so you are not stuck with a binary kernel module that breaks if you breathe too hard near it.
</BLATANT PLUG>
Finally! A year of moderation! Ready for 2019?
Simple - buy a low end S/390 (sorry - zSeries, stupid IBM marketing), get yourself a VM license, and just give each customer thier own complete Linux box. Maintinence becomes really easy too, and it will never go down.
Of course, there is a downside - $500,000 for the Iron, and some outrageous license fee for using VM.
As an aside, I've heard the computer science dept. of one University was going to do this and give each student thier own Linux box to use, as an alternative to shell accounts.
You can see some Linux on VM/390 screenshots here.
_sig_ is away
A rather kludgy solution would be to give every user their own apache process running under it's own account and port, and use ProxyPass from mod_proxy to pass each domain to the port.
/cgi-perl directories.
BBC use ProxyPass on it's webservers to map different mod_perl servers into the
One thing that might work would be to run separate instances of Apache for each client, and use port mangling to route the requests to the appropriate instance.
Say you have clients XX, YY and ZZ. XX runs on port 81, YY:82, ZZ:83. You would then need to code up an IPTables module that would peek at incoming HTTP requests and alter their destination port on-the-fly (this tool might already exist, try Google).
-Billco, Fnarg.com
I haven't seen anybody mention these guys (and they're GPL'd to boot!) so I thought I'd throw in my highly devalued 2 cents.
They seem to have a similar solution to this problem as Ensim does with their Webppliance virtual server suite. Basically making available to each virtual server their own copy of the standard filesystem underneath their /home directory via links and using chroot to keep everyone in their own little area. It seems to work pretty well.
Note: I use an Ensim Webppliance but other than that I really don't know what I am talking about.
IIS already does this, with no problems.
Now, you just have to make sure that IIS doesn't get rooted and you're good to go.
If you dont want them getting into other customers' folders when they login, then why dont you just chroot their environment? Sounds like they dont need much except their web directory so why not isolate them into it.
You can do a lot by chrooting the ftpd you use to allow users to upload files (I highly reccomend proftpd because of it's nice apache-esque config files) locking them into their home directory. That's step one.
/var/www or /usr/local/www or whatever), but that won't stop users from peeking into others directories.
o m
Step two is to deal with PHP, perl, cgi's and whatnot which all run as whatever user the web server is running as. For PHP, for example, you can set the variable open_basedir to force it to not descend any farther than your base document root directory (i.e.
Sadly, the best solution I've found is to cheat and just try and obscure things. Make it not obvious what a given directory might be and then it is much harder for naughty users to look where they shouldn't be. An MD5 sum of the domain name chopped in some fashion, or hell, even a totally random string can be used. You'd then have a website stored something like this:
/var/www/{hash}/www.domain.com
/var/www/{different-hash}/www.differentdomain.c
The user who owns www.domain.com would then need to know what the hash is for www.differentdomain.com to be able to try and access those files. Make your hash generation random or at least very, very non-obvious and you're about as secure as you're going to get with Apache in it's current state.
What i think you're looking for is the jail(8) stuffs for FreeBSD. It lets you boot an entire computer from within a computer. You can then SSH into that computer, etc. With proper setup end non-root users will be very hard pressed to figure out they are in a virtual machine rather than a real one.
Are you in jail?
-If you have unrestricted `ps` capabilities, there will be no 'init' process.
-`df` will show you some procps file systems (4k apeice) mounted under the name of your server or whereever your server was booted from.
Bind multiple IP's to the NIC and bind each instance of apache to an IP, and an instance is started for each virtual host-- which isn't so virtual anymore. It's real-- it's just shared hardware.
"You may all go to hell and I will go to Texas"
Sen. Davy Crocket to US Congress, Nov. 1, 1835
1. CGI-wrappers. It's been a while since I did a big VH server (but I will be this summer as we upgrade our Apache and re-write the site), but it seems like cgi-wrappers helped a lot. I think the way it worked was to set each script with a sticky bit on the owner, and it is owned by the user, and Apache will run the process under that id.
2. Increase max_groups. Hit google for the change in your particular *nix. In solaris edit system file and add "set ngroups_max=32". This does break NFS-- be warned! this includes NAS attached storage. You can then make Apache a member of up to 32 groups (that need write or execute privilege). Don't go all crazy and make Apache a member of every stinkin' group-- remember the group permission is only needed for read, write or execute privilege where the world does not need to go!
"You may all go to hell and I will go to Texas"
Sen. Davy Crocket to US Congress, Nov. 1, 1835
http://www.solucorp.qc.ca
Java provides the basis of a much more coherent security and concurrency model than Apache 1.x + Unix, and products such as WebLogic, JBoss and Jetty take good advantage of it.
Essentially, the thread serving a user's request has their authenticated ID associated with it, and cannot access any resource to which that ID hasn't been explicitly authorized, e.g. in mappings in the web.xml file. If the resource corresponds to an external file or process, it is easy enough to assign it ACLs in the app server and let the server decide whether / how to run it.
The server itself doesn't need to be root.
For example, see the WebLogic security docs - you probably won't find similar these features in free products now, but with the impressive capabilities that Java 1.4 provides it shouldn't be too long before they appear.
I'm not sure if this is only a matter of group ownership of the files.
If this is the question, the solution could be having a few directory levels with different groups:
/home/users/user1/website
/home/users/use r2/website
drwxr-x--- root:users
drwxr-x--- web:group1
drwxr-xr-x user1:other
This way, only users in the group users could cross de first dir, then only THE web user and THE user with group group1 could cross the second dir, then everybody could cross the third level, but in fact, everybody only means web and group1 (user1).
So, you only need one group per user and you don't need the webserver user to be in all groups.
Is this ok?
Miquel