sudo built with --with-secure-path is problematic

[tblumer]

Binary package hint: sudo

For developers who do cross-compiling (for example), sudo needs to inherit the path of the user invoking the sudo command. A better solution is to build without this option and instead alias 'sudo' to 'sudo -i' in user accounts (or /etc/bash.bashrc). At least this method may be easily undone by developers who need to use the sudo path inheritance. OR, provide a command-line option to permit the path inheritance.

[Benjamin Hawkes-Lewis (benjamin-hawkeslewis)]

Worse still, as far as I can tell, it is impossible to respecify secure_path in the sudoers file. So if, for example, you want to offer your users easy access to something under /opt, you must recompile sudo.

The hard coding of secure_path also breaks the general Ubuntu convention (as I understood it) that /etc/environment's PATH entry is authoritative for the system.

[Benjamin Hawkes-Lewis (benjamin-hawkeslewis)]

Looking at it a bit more, the impossibility of overriding --with-secure-path is an ancient bug: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85123 .

[Martin Pitt (pitti)]

Workaround:
  sudo env PATH=$PATH <command>

I am veeeeery hesitant to drop --with-secure-path. We cannot automatically transition existing /etc/sudoers file and we must not change semantics on upgrades.

[Benjamin Hawkes-Lewis (benjamin-hawkeslewis)]

Rather than dropping --with-secure-path, we should restore sudo's original ability to override the compiled-in secure path with an entry in /etc/sudoers. That way there would be no problem with upgrading, as existing /etc/sudoers would work the same as always. I did some work on this a month or so ago, and actually did succeed in getting this working. Unfortunately, in doing so I created another bug that I couldn't solve because of my ignorance of C. But I'm attaching the diff of my changes in the hope that someone else more knowledgeable can pick up where I left off. I've attached a diff for the sudo source package, but it may well be in the wrong format. If it is, let me know how to create the right sort of diff for you from a sudo source package.

PROBLEMS:

There were two big problems with my changes, and I couldn't work out what was causing them:

(1) "sudo -i" now fails with the error message "-bash: /bin-bash: No such file or directory", although "sudo bash" and "sudo /bin/bash" both work.

(2) In sudo.c, I tried to move the call to the method that sets sudo's variables (init_vars) to after we've read sudoers data from LDAP and the local system. Unfortunately, I kept getting a segmentation fault if I didn't *also* make the call before doing so.

INSTRUCTIONS

Anyhow here's how to use and test sudo with my changes:

1. IMPORTANT: Download a spare, emergency copy of the sudo deb before you begin.
2. Download, compile, and install GNU Hello with a prefix of /opt/hello.
3. Add /opt/hello/bin to your PATH in /etc/environment. Reboot to implement your new PATH.
4. Verify that "hello" works but "sudo hello" doesn't:

you@yourhost:~$ hello
Hello, world!
you@yourhost:~$ sudo hello
Password:
sudo: hello: command not found

5. Download the sudo source, apply my changes, and build the package.
6. IMPORTANT: Open a TTY session and "sudo -s". This session will allow you to fix your system easily by reinstalling the spare copy of sudo with "dpkg -i" if/when things go horribly wrong.
7. Now install your customized sudo.
8. visudo and add the following single line at the top of the #Defaults section:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/opt/hello/bin"

9. Now verify that both "hello" and "sudo hello" work:

you@yourhost:~$ hello
Hello, world!
you@yourhost:~$ sudo hello
Password:
Hello, world!

10. Test whether sudo can open a shell correctly (this will fail):

"sudo -i"

11. Test whether sudo can open bash at all (this won't):

"sudo /bin/bash"

12. IMPORTANT: Before uninstalling your new sudo, visudo and comment out the #Defaults line you added in Step 8.

13. Install the current sudo you downloaded in Step 1 with "dpkg -i".

[tblumer (todd-sdgsystems)]

This situation is still the same in Edgy. The current sudo breaks many, many build scripts by not inheriting the path. There really should be a way to override this "feature" without having to rebuild the package.

[sirianni (eric-sirianni)]

Yes. There *needs* to be a way to override this "feature" without having to recompile. Nothing worse then security bigots telling you what's best for your environment and then not giving you a way to turn it off.

Worse, this only appeared to me with a recent apt-get update of dapper. It appears the default compile options have changed within minor bugfix versions?!

[levander (levander)]

I just came across this issue in Feisty, apparently its still there.

A workaround I'm using is to place a link in this secure path to the command I want to run where it already exists on the filesystem.

[Jason (jasonxh)]

This is really annoying. It might be wise to keep current behavior by default for security reasons, but there should be a way of overriding it other than recompiling from source code! Many people ARE in need of PATH inheritance. I wonder why no maintainers look into it, which seems easy to come up with an acceptable solution.

[Kem Mason (bulbousbuy)]

I worked around it like this:

mv /usr/bin/sudo /usr/bin/sudo.orig

then create a file /usr/bin/sudo containing the following:

#!/bin/bash
/usr/bin/sudo.orig env PATH=$PATH "$@"

then your regular sudo works just like the non secure-path sudo

[m4v (m4v)]

yes, not able to override SECURE_PATH is annoying, I added the following alias to my .bashrc for a quick workaround.

alias sudo="sudo env PATH=$PATH"