Answers: <p>No, it's actually <em>really good</em> 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 <code>sudo su</code> instead of just typing <code>su</code> - they want to encourage you to use sudo for it's security benefits. There are few reasons why:</p>
  
  <ul>
  <li><p><strong>Auditing.</strong> When you sudo, the system keeps a record of <em>who</em> 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?)</p></li>
  <li><p><strong>Sudo rules.</strong> Just because a user needs to run <em>something</em> with escalated privleges doesn't mean that they need to run <em>everything</em> with escalated privleges. Using su or adding a user to wheel allows a user to do <em>everything</em>. With sudo however, it is possible to specify what users can and cannot do using <a href="https://help.ubuntu.com/community/Sudoers#Command_Aliases" rel="noreferrer">Command Aliases</a> which allow for the use of wildcards, thereby allowing for flexible rules that grant users privleges to use some commands, but not others.</p></li>
  <li><p><strong>Hardening.</strong> 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). <code>sudo su</code> no longer works. This is done by <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s2-wstation-privileges-noroot.html" rel="noreferrer">setting root's shell to /bin/nologin.</a> 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). </p></li>
  </ul>
  
  <p>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 <em>all</em> the servers in the organization - including probably your log server.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-20T16:04:31.757Z
Answers: 2017-10-20T16:04:31.757Z
Answers: James Shewey
Answers: <p>Whether you allow remote <code>sudo</code> or remote access to something that does <code>SUID root</code> you have a pretty similar attack surface.  I would keep <code>sudo</code> 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.  <code>sudo</code> also has a much longer history in production.  Doing something else will have less history and higher changes of unpleasant surprises.</p>
  
  <p>There are other things you can do to make this more secure though:</p>
  
  <ul>
  <li>tighten up <code>ssh</code></li>
  <li>only allow the restart commands for a few specific users including one for jenkins</li>
  <li>only allow logins for those specific users from all internal IP's or just jenkins and jump box IP's</li>
  <li>store logs on remote boxes so they can't be mucked with</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-19T18:08:19.143Z
Answers: Actually, I just configured my SSH job and it didn't want to run `sudo`: "sudo: sorry, you must have a tty to run sudo"
Answers: amphibient
Answers: CC BY-SA 3.0
Answers: 2017-10-19T18:50:37.477Z
Answers: You might need to give `ssh` the `-t` option.  Or convince sudo not to need it like https://unix.stackexchange.com/questions/122616/why-do-i-need-a-tty-to-run-sudo-if-i-can-sudo-without-a-password
Answers: chicks
Answers: CC BY-SA 3.0
Answers: 2017-10-20T14:57:47.210Z
Answers: How do I supply an option to SSH when it is being called from Jenkins?
Answers: amphibient
Answers: CC BY-SA 3.0
Answers: 2017-10-20T15:23:23.363Z
Answers: I'm not sure about that.  Did you try tweaking `sudo` as the link demonstrates?
Answers: chicks
Answers: CC BY-SA 3.0
Answers: 2017-10-20T21:18:36.897Z
Answers: I managed to enable sudo from Jenkins by changing sudoers on the remote host (SSH target) to not require tty (commented out `Defaults    requiretty`)
Answers: amphibient
Answers: CC BY-SA 3.0
Answers: 2017-10-19T01:18:45.047Z
Answers: 2017-10-19T02:32:13.143Z
Answers: 2017-10-19T02:32:13.143Z
Answers: chicks
Body: <p>I use <a href="https://wiki.jenkins.io/display/JENKINS/Publish+Over+SSH+Plugin" rel="noreferrer">Publish Over SSH plugin</a> to deploy my apps from <code>Jenkins</code> 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 <code>sudo</code>.</p>
  
  <p>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?</p>
  
Tags: <jenkins><security>
Title: Is it bad to use sudo from Jenkins?
UserDisplayName: amphibient
ThreadText: # Is it bad to use sudo from Jenkins?
  
  (Asked by: username_0 on 2017-10-18)
  
  I use [Publish Over SSH plugin](https://wiki.jenkins.io/display/JENKINS/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?
  
  **Tags:** jenkins, security
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-10-20. Score: 7 | Accepted answer
  
  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](https://help.ubuntu.com/community/Sudoers#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.](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s2-wstation-privileges-noroot.html) 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 by username_2 on 2017-10-19. Score: 7
  
  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
  
  > **Comments:**
  > **username_0**: Actually, I just configured my SSH job and it didn't want to run `sudo`: "sudo: sorry, you must have a tty to run sudo"  
  > **username_2**: You might need to give `ssh` the `-t` option.  Or convince sudo not to need it like https://unix.stackexchange.com/questions/122616/why-do-i-need-a-tty-to-run-sudo-if-i-can-sudo-without-a-password  
  > **username_0**: How do I supply an option to SSH when it is being called from Jenkins?  
  > **username_2**: I'm not sure about that.  Did you try tweaking `sudo` as the link demonstrates?  
  > **username_0**: I managed to enable sudo from Jenkins by changing sudoers on the remote host (SSH target) to not require tty (commented out `Defaults    requiretty`)  
  
  ---
  
  