Open Sourcery

An impending doom? Possibly. There was a thread on the Rails Core list not too long ago, titled “Cookie session security and open-source“, and they covered what seems to be an obvious security flaw. I distinctly remember following the events as it happened and thought to myself it makes a lot of sense, and yet I fell victim to the same thing.

PowerDNS on Rails uses the cookie store, and until b2ff9410de[...] had both the session key and session secret hard coded in the environment.rb file.

It came down on my like a ton of bricks when I was moderating a comment by JGeiger on my previous post (Using hoptoad in open source project deployments). I quickly jumped to fix the code using a solution put out by Trevor Turk which requires users to set both the session key and session secret in their database.yml files.

I know this is not an optimal solution, but works until the Core team (and us) have found a reasonable solution to the problem.

As part of stating the obvious (you gotta love hindsight), I recommend anyone who is running PowerDNS on Rails in a production environment to run it over SSL. Apart from session hijacking woes, having your zone data readable as plain text is just as bad as allowing zone transfers to any DNS client…

It came down on me like a ton of bricks when I deployed the audit updates to our production PowerDNS on Rails setup, hoptoad isn’t installed and any errors would just be gone and forgotten.

The solution is pretty simple, if you use git. This quicky will show you how I’m currently doing it.

Multiple remote repos

All our projects have their origin on our own servers, and then either have “github” or “rubyforge” remotes for public changes. This works very well, especially allowing the team here to work on ideas for a couple of days and deploy to a staging/production server for review. Only once we’re happy do we push the code back to the public.

Basic idea is that our public master branches should always be deployable. Nothing sucks more than getting a OSS project and it doesn’t work out the box…

Enter the deploy branch

We all have a tracked “deploy” branch, which exist only in our private repos, not on Github/RubyForge. This deployment branch was used just for our capistrano recipes. As of this week I decided to through hoptoad in the mix as well, which great reward already.

The principle is so simple, hopefully the flow below explains the process.

Master is either your code, or a clone of someone else’s, and the deploy branch contains your modifications for your environment. In our case its capistrano recipes and hoptoad, but could include New Relic’s RPM as well (or anything else).

The deploy branch should have only additions, and no other changes are made to the deploy branch ever. If you accidently merge deploy back to master, you’ll have a tough time undoing the damage.

Capistrano config?

Well, if you maintain your own remote repo of another project, then make sure that repo has your deploy branch at configure capistrano like such:

set :branch, "deploy"

If you don’t want to maintain your own remote repo, but want a local deploy branch, you’ll have to switch to copy deployment recipe (something like this):

set :deploy_via, 'copy'
set :copy_strategy, :export
set :copy_cache, true
set :copy_exclude, ['.git']
set :repository, '.'

BIG FAT DISCLAIMER: I’ve never used the above copy strategy myself, so I cannot vouch for it!

Results?

Well, this neat feature of git allows us to deploy and run our OSS projects as if we were the only users. Sensitive information is not exposed to the world, but is still recorded by hoptoad. It allows us to get the real exceptions as they happen in the wild, without guessing what happened when some logs a “It doesn’t work!!” ticket.

Just as a quick update on the PowerDNS on Rails project, I’ve just pushed several updates to Github that most profoundly includes support for audits. Other smaller changes are also included, including plugin updates (HAML) and upgrading Rails to 2.0.4. As always, these updates have been running in production for a couple of hours already and has solicited some review from our support staff. Undoubtably there will be a lot of tweaks to the feature in the coming days…

Next on the radar is authentication tokens, allowing to give users one-time access to a specific domain for performing updates.

We’ll keep you posted!

As part of our current line of improvements on PowerDNS on Rails, we needed to start auditing changes made through the interface to the DNS data. This is a logical step to opening the system up for more API based interaction, and implementing neat features like macros and temporary authentication tokens.

Auditing in Rails is not for the faint hearted. The Rails Recipes book has an example on how to do this with sweepers, and using the new ActiveRecord dirty object tracking can help ease the problem too. So after some investigation I found the brilliant acts_as_audited plugin by Brendon Keepers.

After playing with it, I realised one short coming. This is very much a problem specifically for PowerDNS on Rails, but after some thought I realized it could be applied to other auditing challenges as well.

Enter parent record tracking

I forked the original project on github, and started hacking. Not too long after I came up with this:

class Author < ActiveRecord::Base
  has_many :books
end
class Book < ActiveRecord::Base
  belongs_to :author
  acts_as_audited :parent => :author
end

Using the sweepers is also possible, like this:

class Application < ApplicationController::Base
  audit Author, Book, :parents => { Book= > :author }
end

As contrived as it can be, it allows us to track all the changes to books by a specific author. In the DNS world this allows us to easily access all changes made to the records of a particular domain, and it becomes very valuable. It becomes even more valuable when you need to start tracking deleted records.

Pull requests were sent to the network, hopefully they get accepted and I can remove my repo again.

Looking forward?

This was a relatively small step forward for the plugin, but opens a lot of possiblities for the host applications, like PowerDNS on Rails. In any ISP environment audits are extremely important, especially when clients start gaining limited access to the backend systems…