Is it bad to use sudo from Jenkins?

Question

I use Publish Over SSH plugin to deploy my apps from Jenkins to different environments. Some deployment jobs do environment preps and things like stop and restart the app server system service. Some of those commands require sudo.

I am just curious if it can be a bad security practice to require sudo within remote publish and execution Jenkins jobs. Should we change the security policy on the target host to allow the required functions to be performed without sudo?

Answer 1

No, it's actually really good security practice to sudo when you need higher level privileges. This is the reason that most distributions prohibit default login and actually force you to sudo su instead of just typing su - they want to encourage you to use sudo for it's security benefits. There are few reasons why:

• Auditing. When you sudo, the system keeps a record of who sudoed and the command they ran. This adds a great deal forensically when you need to go back and figure out what happened - to assign blame, catch nefarious activities or just for troubleshooting purposes (what in the hell happened last night at 7PM before this server went AWOL?)

• Sudo rules. Just because a user needs to run something with escalated privleges doesn't mean that they need to run everything with escalated privleges. Using su or adding a user to wheel allows a user to do everything. With sudo however, it is possible to specify what users can and cannot do using Command Aliases which allow for the use of wildcards, thereby allowing for flexible rules that grant users privleges to use some commands, but not others.

• Hardening. It is possible to disable root. As in, for all intents and purposes, it doesn't exist and is only useful/usable in single user mode - requiring a reboot of a server (and the only reason this is allowed is for password recovery). sudo su no longer works. This is done by setting root's shell to /bin/nologin. which is a great way to prevent many root escalation vulnerabilities. This, of course assumes that you are properly using the bullet above (and you can still grant a specific, admin user all permissions, though this will undermine your security stance).

These things are, of course, only part of your security model. For example, unless you have no users with full administrative privileges (and sometimes even then) your user may be able (probably is able) to delete logs and history - unless you use a log server and syslog to ship logs off-box. Then there's no way to put that cat back in the bag. Of course, if you use a central authentication directory structure, then this comes back into play: If I compromise one account, it is compromised on all the servers in the organization - including probably your log server.

In short, security is complicated, but sudo is a great tool in architecting a secure environment and more people should be using it to it's fullest extent.

Answer 2

Whether you allow remote sudo or remote access to something that does SUID root you have a pretty similar attack surface. I would keep sudo in the chain because it lets you limit the commands easily and has logging that will be vital if you need to audit things later. sudo also has a much longer history in production. Doing something else will have less history and higher changes of unpleasant surprises.

There are other things you can do to make this more secure though:

• tighten up ssh
• only allow the restart commands for a few specific users including one for jenkins
• only allow logins for those specific users from all internal IP's or just jenkins and jump box IP's
• store logs on remote boxes so they can't be mucked with