Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Following on why should we restrict Apache users, another two questions arises:

  1. What is the recommended method of restricting the places Apache users can traverse & read in the file system?
  2. What to do against fork bombs and other shell scripting problems? (bash scripting is allowed)

My possible solutions (I prefer to know which solution you choose and why):

  1. chroot OR mod_chroot
  2. disable bash OR use Restricted BASH

Please offer another solutions if you find appropriate. (perhaps selinux is?)

Current status:

  • Users are allowed to executed bash scripts (via PHP for example)
  • suexec is active
  • Apache requests are served with FastCGI for PHP

Edit:

Sorry for not supplying the bounty yet. The final thing that I need to know is about question #2: when bash scripting is allowed via PHP, how can I defend my system from attacks (fork bombs, reading sensitive data)? Can SELinux/Apparmor defend against those things?

share|improve this question

4 Answers 4

up vote 3 down vote accepted
+50

SELinux or Apparmour are the serious ways of achieve a truly high level of security, and not just for web applications. They're not simple though, however a lot of modern distros have done a lot to integrate them in, Redhat/SELinux and Ubuntu/Apparmour (with the latter considered "easier" to maintain).

If security is something you want to peruse very seriously I'd recommend starting with them asap!

share|improve this answer
    
Can I restrict a specific user from executing certain programs via BASH with SELinux/Apparmor ? –  Dor Feb 18 '11 at 12:45
    
@Dor, yeah. You can pretty such restrict everything! –  Coops Feb 18 '11 at 15:16

Use suexec, run PHP as a FastCGI service (perhaps with safe_mode and open_basedir but these will be deprecated in the future). Due to suexec they shouldn't be allowed into other directories, providing that every website has it's own specialized user, e.g. user1 for /var/www/www.website1.com/ and user2 for /var/www/www.website2.com/.

Modify your /etc/fstab to not allow executable files in /tmp.

If truly paranoid you could disable CGI/FastCGI all together and setup Apache to proxy to standalone applications of your software (Ruby on Rails apps, Catalyst apps etc.). Which in turn are executed by their respective user.

share|improve this answer
    
Despite using suexec, I managed to read files in the filesystem (in /) with PHP functions. I used PHP as FastCGI. –  Dor Feb 17 '11 at 19:45
    
If you don't restrict the actual user and group that owns and execute the file then yes, that is to be expected. If you're executing all files as the httpd user (usually www-data) then it's understandable it can. If you're specifically want to restrict PHP scripts you still can use safe_mode and open_basedir to restrict the user. They'll be around for a while, but eventually get removed as they're deprecated. –  Htbaa Feb 17 '11 at 22:01
    
OK. But would BASH scripting be restricted too? I want BASH scripting to be enabled for users. –  Dor Feb 18 '11 at 7:35
    
The BASH script would be executed as the user that's executing the PHP script, so if the user/group rights are correct then yes. But not with safe_mode and open_basedir I believe. You could also just simply disallow using system() by editing php.ini. –  Htbaa Feb 18 '11 at 8:07

Current trend is just to run light virtualization (openvz, lxc, etc) and separate customers in the system.

This doesn't give you 100% separation of the resources, but greatly reduces risks associated with sharing resources between multiple customers.

In general shared hosting == shared security, you can be sure that somebody will abuse it, no matter how hard you are hardening it ;)

share|improve this answer

In order to ensure that apache-spawned CGIs run as the user that owns them, I rely on suPHP; it's not limited to PHP, can handle arbitrary CGIs with any interpreter, and provides a relatively controllable environment in which to execute them. Once you've nailed the users down to operating as their unprivileged accounts, it's a matter of securing the system against users with login privileges as you normally would (per-user process and memory limits, SELinux policies to protect system files from non-admin users, etc).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.