cc secteam....

HOME can be preserved by removing always_set_home. PATH unfortunately is handled poorly by sudo. You either have no way to set it to a sane default (even with env_reset it gets preserved) or you always have the default without a way to override it. According to the manpage users in exempt_group should not be affected by the compiled in PATH, that doesn't seem to work though.

This worked pretty fine in 10.0.  Currently sudo is completely useless.

PATH handling fixed. Use `Defaults:schwab !always_set_home, !env_reset', permitting this to everyone is security hole, see CVE-2005-2959, CVE-2005-4158, CVE-2006-0151.

It's the only useful behaviour.

Still does not work.

$ grep env_reset /etc/sudoers 
Defaults env_reset
Defaults>root !env_reset
$ type build
build is hashed (/suse/schwab/bin/build)
$ sudo build
sudo: build: command not found

PATH is handled poorly by sudo.

echo -e '#!/bin/sh\nexec /usr/bin/sudo env PATH=$PATH "$@"' > ~/bin/sudo

10.0 regression.

fixed

Why I'm not surprised that it broke again.

If PATH is added to env_keep variables and sudo is configured with --without-secure-path, PATH is not being reset.

If PATH is not present in env_keep variables, it is always reset to secure path specified with --with-secure-path= (currently set to %{_sbindir}:/bin:%{_bindir}:/sbin)

Ludwig: Should I add PATH to env_keep and configure --without-secure-path ?

This problem annoys me as well, there seems to be no way to get a
useful value of PATH with sudo now.

Yes, it is very annoying.. how to revert to the old and working behaviuor ?

(In reply to comment #13 from Cristian Rodriguez)
> Yes, it is very annoying.. how to revert to the old and working behaviuor ?

What was the old and working behavior? Isn't it the first one I described in comment #11? If it is, the fix is simple, but I have to wait for secteam to advise.

Ludwig is back on Monday, so some patience please.

While Ludwig only showed up briefly today, he had the following statement
(I hope I have it correctly).

Allowing unprotected/unchecked PATH or other environment variables by
default makes holes into sudo, because there are then ways to break out
of the predefined applications, allowing the user to become root.


The various sudo security updates we did over the time were all "interesting" environment variables being passed, which could be used to do such an escape.

For local use, you can use env_keep I guess.

But even with env_keep it is not possible to keep PATH anymore
because sudo is now apparently built with

    “configure --with-secure-path=/usr/sbin:/bin:/usr/bin:/sbin”

see comment #11.

I'm confused, STABLE uses --without-secure-path but that change is not mentioned in the changelog. That results in env_keep working but the default path (if PATH is not in env_keep) now apparently is "/usr/bin:/bin" which of course is annoying. I'd suggest to change this hardcoded path to include at least {/usr,}/sbin. This way we can have PATH reset by default to a sane secure value while still beeing able to add PATH to env_keep, e.g.:

Defaults:joesix env_keep+="PATH"

Sounds fair to me.

I have just found out that eg. Debian uses --with-secure-path, but also uses --with-exempt=sudo, which causes that PATH for users in group sudo is not being reset to secure_path if PATH is in env_keep. We do not have group sudo, but maybe could use group wheel for this purpose.

Ludwig: which solution do you like more?

a) Comment#18
   - use --without-secure-path
   - change hardcoded secure_path to /usr/sbin:/bin:/usr/bin:/sbin
   * PATH will be kept if specified in env_keep for all users
   * PATH will be reset to secure_path if not in env_keep for all users

b) --with-exempt=wheel (more secure)
   - use --with-secure-path=/usr/sbin:/bin:/usr/bin:/sbin
   * PATH will be kept if user is in group wheel _AND_ PATH is present in env_keep
   * PATH will be reset if user is not in group wheel _OR_ PATH is not present in env_keep

IMO abusing any group for that purpose just increases confusion. I vote for a).

Package submitted to STABLE - a) variant.
Closing.