<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>

CC BY-SA 3.0
2017-10-20T16:04:31.757Z
2017-10-20T16:04:31.757Z
James Shewey
<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>

CC BY-SA 3.0
2017-10-19T18:08:19.143Z
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"
amphibient
CC BY-SA 3.0
2017-10-19T18:50:37.477Z
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
chicks
CC BY-SA 3.0
2017-10-20T14:57:47.210Z
How do I supply an option to SSH when it is being called from Jenkins?
amphibient
CC BY-SA 3.0
2017-10-20T15:23:23.363Z
I'm not sure about that.  Did you try tweaking `sudo` as the link demonstrates?
chicks
CC BY-SA 3.0
2017-10-20T21:18:36.897Z
I managed to enable sudo from Jenkins by changing sudoers on the remote host (SSH target) to not require tty (commented out `Defaults    requiretty`)
amphibient
CC BY-SA 3.0
2017-10-19T01:18:45.047Z
2017-10-19T02:32:13.143Z
2017-10-19T02:32:13.143Z
chicks
<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>

<jenkins><security>
Is it bad to use sudo from Jenkins?
amphibient
# 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`)  

---

