# restricted ssh shell for ruby on rails hosting ? (rake, git, etc.)



## swix (May 9, 2011)

Hello,

I'm managing a few hosting servers, mostly php-based: customers have SFTP access (via proftpd and mod_sftp), phpmyadmin, etc.  They are "jailed" in their home directory on both levels:  
	
	



```
DefaultRoot ~
```
 for FTP, and open_basedir for PHP, and it's working fine like this. 

Now I have added a few personal ruby on rails hosting on one of the servers (via mod_passenger), and I'd like to do so for other people. Problem: most of the RoR operations will require a ssh shell, for example for rake db:migrate, local gem installation, debugging, and local git repository management as well. I presume I am not the only one in this situation: if it is the case on your systems, may I ask how to you handle this case, to maintain the best overall system security?  

I just saw shells/ibsh in the ports list which could have helped, but it doesn't really seem to be maintained (last update was in 2005). 

The rails user can't browse other user's directories (solved simply with unix filesystem rights), and he can't see other processes (security.bsd.see_other_gids=0, security.bsd.see_other_uids=0, etc.), but one of the thing I would like to prevent is for example accessing some files like /etc/passwd (= listing all other customers domains in this specific case).  

Other things would be: 
- prevent the launch of daemons  (-> screen, irssi, bots, etc.) -> ?
- prevent the use of *crontab -e*  (for some people): /var/cron/allow|deny

The document under http://www.bsdguides.org/guides/freebsd/security/harden.php is a good help, but not for all points...  And it's also from 2005. 


Any suggestion welcome 
Merci & regards,
Olivier


----------



## SirDice (May 9, 2011)

You can't prevent access to /etc/passwd. It needs to be world readable or your entire system will break.

One solution is to circumvent local accounts completely and use something like LDAP.


----------



## swix (May 9, 2011)

That's exactly the point. Or maybe there is something possible with ACLs?

Otherwise another solution (for me) would be to anonymize the data contained in /etc/passwd, but it's also a bit overkill for this "simple" problem.


----------

