

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"<p>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.<p>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.<p>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.<p>Does anyone do a setup similar to this?  Would this have limited the recent YAML exploit?<p>Is this a valid practice or being overly concerned, thoughts?<p>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.

