views:

2248

answers:

5

Within Ruby on Rails applications database.yml is a plain text file that stores database credentials.

When I deploy my Rails applications I have an after deploy callback in my Capistrano recipe that creates a symbolic link within the application's /config directory to the database.yml file. The file itself is stored in a separate directory that's outside the standard Capistrano /releases directory structure. I chmod 400 the file so it's only readable by the user who created it.

  • Is this sufficient to lock it down? If not, what else do you do?
  • Is anyone encrypting their database.yml files?
+7  A: 

You'll also want to make sure that your SSH system is well secured to prevent people from logging in as your Capistrano bot. I'd suggest restricting access to password-protected key pairs.

Encrypting the .yml file on the server is useless since you have to give the bot the key, which would be stored . . . on the same server. Encrypting it on your machine is probably a good idea. Capistrano can decrypt it before sending.

James A. Rosen
+2  A: 

If you're very concerned about security of the yml file, I have to ask: Is it stored in your version control? If so, that's another point where an attacker can get at it. If you're doing checkout/checkin over non-SSL, someone could intercept it.

Also, with some version control (svn, for exampl), even if you remove it, it's still there in the history. So, even if you removed it at some point in the past, it's still a good idea to change the passwords.

Micah
I never store database.yml in my source control repositories.
John Topley
+1  A: 

Even if you secure the database.yml file, people can still write that uses the same credentials if they can change the code of your application.

An other way to look at this is: does the web application have to much access to the database. If true lower the permissions. Give just enough permissions to the application. This way an attacker can only do what the web application would be able to do.

Peter Stuifzand
+4  A: 

The way I have tackled this is to put the database password in a file with read permissions only for the user I run my application as. Then, in database.yml I use ERB to read the file:

production:
  adapter: mysql
  database: my_db
  username: db_user
  password: <%= begin IO.read("/home/my_deploy_user/.db") rescue "" end %>

Works a treat.

Olly
How does this improve on setting read permissions for the application user directly on database.yml?
John Topley
I took this approach because, a) the password isn't in database.yml and hence isn't committed to source control, and b) other than putting the password in a file on the production server only, there was no other work required -- no Capistrano tasks, no files outside of the main structure etc.
Olly
I feel that the database.yml shoudn't be in the repository in the first place because every developer should be able to define their own working environment.
Jaryl
If every developer is developing with an app-local sqlite database and not a database server, and if there is only a single canonical production deploy (on multiple identically-configured servers) and not multiple production deploys, then it is fine to keep `config/database.yml` in source control. This is the default way to do it in Rails. If your setup is more complicated than that, then you may not be able to keep `config/database.yml` in source control.
Justice
A: 

Take a look at this github solution: http://github.com/rsutphin/bcdatabase. bcdatabase provides an encrypted store where the passwords can be kept separated from the yaml files.

bcdatabase

bcdatabase is a library and utility which provides database configuration parameter management for Ruby on Rails applications. It provides a simple mechanism for separating database configuration attributes from application source code so that there's no temptation to check passwords into the version control system. And it centralizes the parameters for a single server so that they can be easily shared among multiple applications and easily updated by a single administrator.

slm