In a shared web-hosting environment, there are a couple issues that you need to address right off the bat.
Regarding directory permissions and only being able to access your files: what you want to do is set home directory permissions such that the "others" group has no permission whatsoever. Remember that eXecute permission is needed to cd into directories, but that by itself won't allow you to read their contents. Therefore, /home should be owned by root and have rwxr-x--x, so users can only "blindly" go to their home folder but not have a peek around and know how many users are in your system. It would look something like this (date, size etc omitted for clarity):
# ls -la /home
drwxr-x--x root root .
drwxr-xr-x root root ..
drwxr-x--- usr1 usr1 usr1
drwxr-x--- usr2 usr2 usr2
...
If you really don't want users to be able to read the contents of directories like /bin
, etc. simply remove the "read" permission bit for the "others" group. It will not affect their ability to use the binaries contained within, provided they know the full route beforehand.
For SSH and FTP access, if you configure your filesystem permissions correctly, then any decent SSH or FTP implementation will already be secure. I recommend vsftpd for FTP, of course OpenSSH for SSH, but by no means I imply they're the only correct options available. Remember to tweak configuration options for those services (in particular, disallow root login through SSH, probably disallow password login for anyone sudo-capable, etc.)
The tricky part is configuring your web server correctly, especially if you have to run CGI scripts for dynamic websites. Everyone and their grandmother want PHP these days, and you really can't have /home/dumbuser/public_html/php_shell.php
running as the same user that spawned your Apache/Nginx, right?
A possible solution here, if you're running the Apache web server, is to use the suexec module, which will have your CGI script run as the user that owns the executable file (think setuid bit). To allow the HTTP server access to the actual files, consider adding the user the server runs as (typ. www-data
) to every user group on the system ("every user group" meaning every user that's using your shared environment, not every user account on the system).
Note that this is barely scratching the surface of all that must be done to properly configure and harden a shared server. The configuration files for each service running must be completely understood, and you will probably have to modify them to suit your needs. In particular, you'll probably have to spend a good week reading configuration options for your web server and trying it out on a development/testing environment.
ls -ald /usr
andgetfacl /usr
? It doesn't sound like a chroot environment if they have to lock down the permissions like that. – user3188445 Aug 16 '15 at 21:39/home
. – Creak Aug 17 '15 at 00:05