Lighttpd

If your CGI scripts are limited to php, you could try php-fpm.
If not, there is also suEXEC that allows setting uid of the cgi process.
No point in running lighty for each user ^^

wow php-fpm looks really cool, thanks

Still, I can see advantages of running lighty for each user. If php-fpm works for me though, I won't be trying it.

running lighttpd/php/any other CGI/FCGI capable script language as the same user that owns the files is not improving the security, it just makes it easier to hack the box.

You are welcome.
If you have any questions regarding php-fpm, don't hesitate to ask.
You can catch me on lighty's IRC channel.

darix wrote:

running lighttpd/php/any other CGI/FCGI capable script language as the same user that owns the files is not improving the security, it just makes it easier to hack the box.

Why? I know it makes it easier to hack the specific user's account but the whole box? o.O

you dont need root to run a bot net or so. and besides ... the next root exploit isnt too far away anyway. (or maybe even old ones still work.)

you blindly violate the rule of least permissions.
you can run apps/webserver as a different user for each vhost, but not as the file owner.

I still have a feeling that running fcgi as (for example) nobody would only irritate my clients instead of making it more secure.
In my config it disables users from looking up files of others.

Do you think open_basedir would be better for that?

my current solution is

/srv/www/vhosts -> permissions 0711
# readable by user
/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/
# writable by user
/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/data/
/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/htdocs/
/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/sessions/
/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/tmp/

that means if the app isnt stupid enough to leak the path you got relative safety. i know it is a bit security by obscurity.

then i set up one fastcgi listener per user
in case of php they get their own php.ini which sets openbasedir/sessionpath/tmp dir and so on

open_basedir = /srv/www/vhosts/<sha1sum>/domain.tld/subdomain/
upload_tmp_dir = "/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/tmp" 
session.save_path = "/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/sessions/" 
soap.wsdl_cache_dir="/srv/www/vhosts/<sha1sum>/domain.tld/subdomain/tmp" 

in the fastcgi.server block you just set

"bin-environment" => (
  "PHPRC" => "/etc/php5/vhosts/<sha1sum>/" # directory got the same permissions as the "/srv/www/vhosts/<sha1sum>/"- subdir. the file in it is named php.ini
  ....
)

$HTTP["url"] ~= "^/wp-content/uploads/" {
  fastcgi.server = ()
  cgi.assign = ()
  scgi.server = ()
}

that makes sure it doesnt try execute any files directly from there.

and last but not least every (Fast|S)CGI app gets their own apparmor profile that locks it down to the area i needs access to.
if you start the same app multiple times, e.g. php, then you need a wrapper script and tie the profile to that.
and by default all apparmor profiles deny writing to htdocs

with all that you can run all fastcgi stuff as the same user and are still pretty safe.

Darix,

I agree that there are risks involved in executing files as their owner, but this does not make it easier to hack the whole box, run a bot net, or use a root exploit. Besides, this is not what I was meaning to do.

The reason I think running stuff as individual users improves security is because your security is based on a low level, and because you make use of the well-tested security of the *nix operating system itself. If we wouldn't have abandoned this level by using a single application for many users in the first place, we would not have a problem at all.

I once read a PHP mailing list where the developers explained why they removed safe mode in PHP 6; it's the wrong level to implement this kind of security, and because of this introduces a risk of failure. You make people believe their web server is secure but depending on their setup there can actually still be flaws. (By the way: I don't think open_basedir provides much security when not using safe mode. And those SHA1 hashes: you put the responsibility of hiding their paths in the hands of your users. You might as well use suphp in that case.)

Other downsides of open_basedir setups: irritates users in many ways, it's no solution for other cgi scripts, hard to monitor per-user activity.
Advantages of running scripts as individual user: scripts are allowed to run "freely" - no need to disable certain functions etc. and scripts can write to disk without the need of setting 777 permissions, and you can benefit from linux' robust security and improve this even more by tools like ulimit.

I hope that explains my choice :)

btw @radzio

php-fpm provides "Ability to start workers with different uid/gid/chroot/environment", but you don't necessarily need php-fpm for that. The problem remains that with lighttpd you can't assign a virtual host to a specific fastcgi worker. Or can you?

//edit: I was wrong, it is possible. See http://redmine.lighttpd.net/wiki/1/HowToSetupFastCgiIndividualPermissions.
Guess I once tried it, failed, and assumed it wasn't possible...

Sure you can, just wrap it into a host-conditional and point it to port/socketfile your backend is running at as desired user $foo.

lennartack wrote:

btw @radzio

php-fpm provides "Ability to start workers with different uid/gid/chroot/environment", but you don't necessarily need php-fpm for that. The problem remains that with lighttpd you can't assign a virtual host to a specific fastcgi worker. Or can you?

//edit: I was wrong, it is possible. See http://redmine.lighttpd.net/wiki/1/HowToSetupFastCgiIndividualPermissions.
Guess I once tried it, failed, and assumed it wasn't possible...

If it wasn't possible, I wouldn't suggest you php-fpm :P