2

I'm having problems dealing with Apache configuration: the problem is that I want to limit each user to his own docroot (so, a chroot() would be what I'm looking for), but:

  • Mod_chroot works only globally and not for each virtualhost: i have the users in a path like the following one /home/vhosts/xxxxx/domains/domain.tld/public_html (xxxxx is the user), and can't solve the problem chrooting /home/vhosts, because the users would still be allowed to see each other.
  • Using apache-mod-itk would slow down the websites too much, and I'm not sure if it would solve anything
  • Without using any of the previous two, I think the only thing left is avoiding symlinking, not allowing the users to link to something that doesn't belong to them.

So, I think I'm going to follow the third point but... how to efficiently avoid symlinking while still keeping mod_rewrite working?!
The php has already been chrooted with php-fpm, so my only concern is about Apache itself.

Alessio Periloso
  • 188
  • 1
  • 9
  • Multilpe Apache instances, one per vhost (upgraded to actual host)? If they share an IP: behind a proxy, just on another port on localhost? THen it's even easy to run apache as the user itself. – Wrikken Jun 26 '12 at 21:45
  • Have you looked at mod_security to chroot apache? – nwalke Jun 26 '12 at 21:47
  • 1
    @Wrikken Yes, that would be a solution but however, would cost a lot of ram. That's why I was looking for another, viable, solution. Running more instances would be really interesting when having each user in his own "box" (like with OpenVZ)... but then I would sell VPSs and not shared hosting anymore! :P – Alessio Periloso Jun 26 '12 at 21:48
  • @tubaguy50035 I was just going to look at it; as far as I've understood however, it seems I still can't chroot every virtualhost to his own directory, like with mod_chroot... am I wrong? – Alessio Periloso Jun 26 '12 at 21:52
  • Yep, you got a point there... I haven't done it any other way though, so I'll leave it to others then (I'm sure there's a decent answer, you might even look at packages like cpanel et al. how they do it atm). – Wrikken Jun 26 '12 at 21:53
  • @AlessioPeriloso, I have not personally used mod_security that way, I'm looking for the same thing though. It looks like you can do it on a per vhost level by setting the `SecChrootDir` per vhost. – nwalke Jun 26 '12 at 21:55
  • Also, how did you get around the 404 issues between chrooted php-fpm and apache? – nwalke Jun 26 '12 at 21:57
  • 1
    @tubaguy50035 i am trying to install mod_security and setting the SecChrootDir inside the virtual hosts... will let you know what happens :) About the 404 (or... the "No input file." error), I've solved the problem using a proxy between apache and php-fpm. After trying to edit the php-fpm source code, I've realized it wasn't linear at all and I would lose too much time with it. So I wrote a proxy between Apache and php-fpm in python to change the variables with the ones that would be correct inside the chroot environment. If it would be useful, I've used the python flup library to do it :) – Alessio Periloso Jun 26 '12 at 22:08
  • 1
    @Wrikken I've already fixed the problem about symlinking (I will add the solution as an answer here in a while), but it seems SecChrootDir does really works in every single virtualhost... so I could chroot every user to his own environment, avoiding VPSs. There are still some errors to be solved though: apache doesn't argues it can't be done, but says that there's no socket for fastcgi and probably some problems about the non-existant directories (obviously). Will let you know soom :) – Alessio Periloso Jun 26 '12 at 22:12
  • Let us know what you find out. I'm trying to do the exact same thing with my setup. – nwalke Jun 27 '12 at 04:39
  • 1
    @tubaguy50035 I think i've managed to secure apache enough using the SymLinksIfOwnerMatch option, also because the mod_security chroot seems to hang apache processes around (I have to kill them manually and I'm not sure what happens with a graceful restart). About the php-fpm solution, I can't dislose the source code because my company owns it, but anyway, using the flup library and using both the server and client classes can help you rewrite the variables, making fpm working. Just make sure to listen to a port mod_fastcgi can connect to, and to connect to php-fpm to make the proxy ;) – Alessio Periloso Jun 27 '12 at 08:55

2 Answers2

2

Anyone coming across this post would do well to note that Apache describes SymLinksIfOwnerMatch as not being a proper security measure:

This option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable."
(from http://httpd.apache.org/docs/2.2/mod/core.html#options).

Aside from just disallowing symlinks altogether and preventing users from overriding that setting in .htaccess files, to see a write-up of solutions out there for preventing symlink attacks, check out https://documentation.cpanel.net/display/EA/Symlink+Race+Condition+Protection (it's not just cPanel specific).

sa289
  • 1,308
  • 2
  • 17
  • 42
1

Why do you need to restrict apache itself? Would it not be better/sufficient to lock your script runtime (php, Perl, ruby, ...) in a chroot? If so, look at mod_fastcgi and how to start a persistent interpreter for the particular language(s) you require.

ukautz
  • 414
  • 2
  • 2
  • I am already locking php into a chroot through php-fpm, and I'm thinking about a persistent interpreter for perl too... but having Apache users everywhere isn't going to make me sleep well :P However, I've added the "SymLinksIfOwnerMatch" option inside the virtual hosts declaration, and it seems to work pretty well, not allowing people to go outside the jail. But is it safe enough? – Alessio Periloso Jun 27 '12 at 08:49
  • 2
    I'd think so. However, if you are prepared to "go the extra mile", look into Linux security enhancements, such as SELinux, GRSecurity, Tomoyo and so on. With those, you can limit the user's access on a more precise level (read about [MAC](http://en.wikipedia.org/wiki/Mandatory_access_control) and [RBAC](http://en.wikipedia.org/wiki/RBAC) to get the drift). Also you can [strengthen your chroot](http://www.bpfh.net/simes/computing/chroot-break.html/). – ukautz Jun 27 '12 at 09:57
  • Oh, thank you very much for all these information... I've really appreciated them! :P Probably there would be some problems with GRSecurity and SELinux, since I am using OpenVZ containers, but in the meantime thank you for your useful advices! :P – Alessio Periloso Jun 27 '12 at 16:14
  • I think "Why do you need to restrict apache itself?" is what people were saying until symlink attacks started happening in the wild where you could trick Apache into serving another user's database u/p from a PHP file as plaintext, and now it's "I hope we've restricted Apache enough" =). – sa289 Jul 16 '15 at 23:11