Re: Debian´s change of "su" to the one in util-linux

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Sun, Aug 05, 2018 at 10:35:34AM +0200, Martin Steigerwald wrote:
> Now people say, including Debian maintainer of util-linux, in above NEWS 
> file entry: Using "su" without initializing new environment is a bad 
> idea and should never be done. For many reasons. However, nowhere I saw 
> these reasons actually mentioned. That is not enough for an informed 
> decision about it. I already opened a bug report for util-linux package 
> about no concrete reasons provided:
> 
> util-linux: su from util-linux: no reason why su without setting new 
> environment is bad idea
> https://bugs.debian.org/905478

The reason why preserving the environment across a su or a sudo can be
dangerous is that environments that are meant for use by an
unprivileged process might not be appropriate at all when running as
root.  There are lots of potential reasons why.  Here are some:

* The PATH might include the current directory, and so a script
  running as root might accidentally get the wrong/unexpected binary.
  This could lead to a security breach.

* Some environment variables might cause debugging or logging
  information to go to a specified file.  If a malicious user can
  control that environment variable, bad things can happen when the
  user is running as their own uid.  But even *worse* things can
  happen if the user is running as root.

So the basic security principle here is that scripts should be tested
and run using a single runtime environment.  If the Administrators
Alice and Bob have different environment variables set in their dot
files, then some administrative script might behave differenly
depending on whether Alice or Bob runs the script.  And worse, maybe
Charlie has a third set of environment variables that might cause the
script to do something catastrophically wrong.

So for that reason, it makes sense that a "sudo" or "su" command
should default to something safe.  

> And then: How to implement a backup script that needs root access for 
> most operations, but also requires access to SSH agent from a user 
> setup? Dig out the environment variables of the SSH agent myself? Let 
> the script run as a user and use "setprivs" that is mentioned as 
> recommend in the "su" manpage, yet is in a different package altogether 
> and not part of "util-linux".

You might want to look at the man page for sudo, and its configuration
files, especially sudoers.  It has a *huge* amount of fine-grained
controls over which environment variables should be reset, and which
ones which should be preserved, and whether or not a particular user
should be trusted to override environment variable processing on the
command line.

You can do this on a per-command or per-user basis, and you can do
things like allow some kinds to not require typing a password if it is
a "safe" thing for some set of users to do (perhaps with some controls
over time of day, or what environment variables can be manipulated,
etc.)

Cheers,

						- Ted