This post originated from an RSS feed registered with Ruby Buzz by Guy Naor. Original Post: Capistrano (aka SwitchTower) and security Feed Title: Famundo - The Dev Blog Feed URL: http://devblog.famundo.com/xml/rss/feed.xml Feed Description: A blog describing the development and related technologies involved in creating famundo.com - a family management sytem written using Ruby On Rails and postgres Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Guy Naor Latest Posts From Famundo - The Dev Blog

You already know I ABSOLUTELY love Capistrano (well, I do prefer SwitchTower as a name...). I also count security as a critical component in any production system (and no, having a firewall doesn't count as security). So to make sure I can comfortably use it in production, I had to make some security adjustment on the machines I deploy to.

Some important requirments:

1. The web server should only have read access to the absolute minimum it really needs. In my case, as I'm using FastCGI processes launched from outside the server, only the public directory needs to be readable by it.
2. The deployment user (set :user "deployer" in deploy.rb) should be a distinct user and should be the only one with write privileges to the rails application directory.
3. The rails application runner will be itself a distinct user with only read access to the rails application.
4. All other users can't even read the deployment directories.
5. The deployment user can run as root using sudo only the minimum number of things like restarting the web server, or changing configuration.

To satisfy those requirement I created 2 users - one to deploy and one to run the rails application. I then set the privileges on the files (using chmod) so that the runner can read everything in the rails app directories and write just to the log directory. And the web server can read only the public directory. Then I edited the sudoers file (use visudo and direct editing to catch syntax errors) and allowed the deployment user rights to launch/stop/reload the web server, and to copy some configuration files. Note that it can't write to the files. It can just copy them from one specific location to another. It's risky letting someone to sudo run shell scripts, as then they can do anything like root. Here's a piece of my sudoers file:

Cmnd_Alias      CP_LIGHTY_CONF = \
    /bin/cp  /etc/lighthttpd/maintenance.conf /etc/lighttpd/lighttpd.conf, \
    /bin/cp /etc/lighttpd/application.conf /etc/lighttpd/lighttpd.conf, \
    /etc/init.d/lighttpd

deployer    localhost = CP_LIGHTY_CONF

This gives the deployer user the rights to copy the config files around, but not to ever write to them. So that the admin on the box set them as needed, but the deployer can change them as needed.

Please note that this is only one layer of the security. Just like the firewall is just a single layer. When planning a deployment, think of security as a layered mechanism, adding more and more layers (firewalls, host firewalls, privileges, monitoring, IDS, SELinux, etc...).