capistrano-3-rails-template
capistrano-3-rails-template copied to clipboard
TalkingQuickly
sudo password
Hi
How can I running deploy command without password? I have a deploy user in shudders.
Is the problem that you're being asked for the sudo password when you deploy?
I had to add the following to my sudoers file with sudo EDITOR=vim visudo:
deployer ALL=NOPASSWD:/bin/ln -nfs /home/deployer/* /etc/nginx/sites-enabled/*
deployer ALL=NOPASSWD:/bin/ln -nfs /home/deployer/* /etc/init.d/*
deployer ALL=NOPASSWD:/etc/init.d/nginx reload
deployer ALL=NOPASSWD:/etc/init.d/unicorn_treescript_production restart
deployer ALL=NOPASSWD:/usr/sbin/service unicorn_treescript_production restart
Where deployer is the name of my deployment user. This is because Capistrano 3 favors the passwordless sudo method of executing sudo commands.
Thanks @christiangenco , I'm working on something to automate setting that up, will keep this issue open until I've got something available
Is this how Capistrano 3 wants us to do it? Seems a bit clunky. Also, by not being verbose I'm likely exposing myself to some kind of symbolic link exploit (allowing deployer to link anything in /home/deployer with anything in /etc/nginx/sites-enabled, etc.).
At the moment I can't see a better approach, going to experiment this weekend with the minimum permissions we can get away with in the sudoers file while still allowing flexibility of different configs on the Capistrano side.
The only one that bothers me is allowing links to be created to /etc/init.d/, but since we only allow links to be created, not commands executed, it seems like there's limited damage which could be done?
With what permissions are things in /etc/init.d/ executed? Could the deployer user create a malicious script, make it executable, symlink it into /etc/init.d/, and gain more privilages than it would have had otherwise?
Most scripts in /etc/init.d (because that are executed at startup/shutdown) are run (at least initially) by the root user
On 9 May 2014, at 01:05, Christian Genco [email protected] wrote:
With what permissions are things in /etc/init.d/ executed? Could the deployer user create a malicious script, make it executable, synlink it into /etc/init.d/, and gain more privilages than it would have had otherwise?
— Reply to this email directly or view it on GitHub.
To me the biggest hole is that we want the user to be able to create symlinks such as /etc/init.d/unicorn_something in /etc/init.d and we also need them to be able to execute them. That means that in theory if an attacker gained access to the deploy user, they'd be able to symlink something containing arbitrary code which followed the allowed naming convention to /etc/init.d/something and then execute it with as root with sudo.
That said, if a malicious user has got access to the deploy user in this configuration they can already change anything about the running web app and get database access so I'm not sure how much worse root access really makes it?
That's a fair point, and you perfectly echoed my concerns.
What is sudo protection really preventing? Potential leaks in Rails (or whatever middleware you're using) that would allow arbitrary code execution?
I don't think there's any way around giving the deployment user a "dangerous" set of permissions. But maybe unicorn does not need to run as the deploy user? At least the dreaded "arbitrary code" would be executed with less privilege.
perhaps we just need to leave deploy_user as unprivileged as it is, and create a newer user just for deploy:setup_config? in fact, shouldn't that be root? what do you thinkg @TalkingQuickly?
Ooo, I love the idea of setting up as root - that makes a lot of sense, and solves all of these problems.
Is there a downside?
For whoever is still following this repo, adding the following line will get rid of the error sudo: no tty present and no askpass program specified:
put set :pty, true under set :application, 'APP_NAME'
