Ask HN: Principle of Least Privilege in Rails?

[rschmitty]

Hello, I'm still flushing out a migration from php to rails and was wondering about security practice of "principle of least privilege"

In php we ran apache under apache:www, we had a deploy user called deploy. All files/folders would be deploy:deploy for ownership. Whenever an application required write access to a file or folder (like logs, user uploads, caches, etc) we would `chmod g+w some_file_or_dir` and `chgrp www some_file_or_dir` The idea being you strictly control what is written should someone exploit apache/your web app.

I was able to set this up with Passenger by specifying `PassengerDefaultUser apache` and `PassengerDefaultGroup www` after disabling user switching. Again we are not hosting other agency's, all apps are owned by us hence our single deploy user. I also set /var/www/.passenger folder to be owned by www. Finally for all the rails apps I had to set the group to www for the logs folder. If there were some file uploads I set www to that folder as well.

I'm a developer first and foremost and don't claim to be a system admin, this was just a practice they beat into me over the years of php dev.

Does anyone do a setup similar to this? Would this have limited the recent YAML exploit?

Is this a valid practice or being overly concerned, thoughts?

I have not looked into this for unicorn based deployments like rbenv/37signals suggests and I believe github/twitter also use unicorn. I started with passenger since that was a similar setup to php/apache vs nginx/unicorn

[rst]

It's possible to mount the file system containing the production build of a Rails app (after "rake assets:precompile") completely read-only. In fact, Heroku, one of the more common cloud-management providers for Rails apps, does exactly that --- which means that if you want to support file uploads, you've got to stick the contents somewhere other than the file system. (Amazon S3 buckets are one popular choice.[1])

[1] https://devcenter.heroku.com/articles/paperclip-s3

That said, this sort of setup might have made the recent YAML bugs somewhat more awkward to exploit, but it wouldn't defang them. What those exploits allow an attacker to do to an unpatched app is cause it to run arbitrary code immediately and directly; there's no second step. Even if they can't write the file system, they have any number of ways of getting information back to the attacker. So... get patched, I guess.