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

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

[Martin Steigerwald]

Hello.

A new version of the util-linux package for Debian switched the "su" 
implementation from the one from the "shadow" package to the one in the 
"util-linux" package.

Now "su" from "util-linux" preserves PATH and IFS unless you use "su -" 
login shell mode. An item in the NEWS.Debian file explains that change:

https://sources.debian.org/src/util-linux/2.32-0.4/debian/util-linux.NEWS/

This difference broke an existing work-flow for me: I have a backup 
script that backups my laptop and my remote servers. It needs root 
access for creating BTRFS snapshots and for storing the actual data with 
ownership preserved. However, for accessing the remote servers it needs
access to the SSH agent running in the user session. The backup scripts 
uses commands that are in "sbin" related directories.

As the explanation was in the NEWS file was not there initially the 
first thing I did was to hard code the path in the backup script. Then 
even with the explanation I am not all that satisfied with the change in 
behavior and for now just set "ALWAYS_SET_PATH yes" in "login.defs".

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

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

Also… login.defs manpage from shadow project does not mention 
"ALWAYS_SET_PATH", but manpage of su from util-linux does mention it. 
And there does not appear to be a manpage about "login.defs" in "util-
linux" package at all. (I found before that there appears to be a huge, 
big mess about some things in "util-linux", some in "shadow" and some in 
both).

http://man7.org/linux/man-pages/man5/login.defs.5.html

http://man7.org/linux/man-pages/man1/su.1.html

And it does not say why it would be a bad idea to just use it. Also the 
manpage does not say anything bad about using "su" without login shell 
mode.

So what is up here from upstream point of view?

Why would "su" without initializing environment be a "bad" idea? And how 
else to implement a backup script with access to SSH agent in the 
"proper" way?

Now all the fuss might be difficult for you to understand since other 
distributions use su from util-linux for a long time already. But for me 
there are currently really quite some question marks about what to use, 
what not to use and most importantly *why* to do so. There is quite some 
confusion. Debian used "su" from "shadow" package since… ages.

I may share some of your insights with the Debian bug report I 
mentioned, to help the maintainer to improve the wording that explains 
the change.

Thanks,
-- 
Martin

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Sun, Aug 05, 2018 at 10:35:34AM +0200, Martin Steigerwald wrote:
[...]
> 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?

If all you need from the ssh agent is the socket, then just symlink it
to a fixed location trusted both by you and by root, then you can override
$SSH_AUTH_SOCK to the new location, e.g.

if [ -S "$SSH_AUTH_SOCK" ]; then
	ln -snf "$SSH_AUTH_SOCK" fixed_trusted_location
	SSH_AUTH_SOCK=fixed_trusted_location
fi


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Theodore Y. Ts'o]

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

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

[Martin Steigerwald]

Theodore Y. Ts'o - 05.08.18, 17:05:
> 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
[…]
> So for that reason, it makes sense that a "sudo" or "su" command
> should default to something safe.

Thank you, Ted. This is the best explanation I saw so far. I accept it 
for default.

In my specific case I still do not see any big issue with that cause the 
backup script runs on my laptop, the user I "su" from and "root" are 
both users only I have access to. So the risk in my case may mostly be 
that the script would pick an an inappropriate command. Due to me 
installing it. Someone who would get access to an regular user account 
could set up a bogus path as the user and install a malicious command 
there in order to gain "root" access or so. In my understanding of 
security it would be already too late if someone gained access to an 
user account on my laptop without my permission.

However I just tested on Debian by logging in as "root" on "tty1" and it 
still gives me "~/bin" and the "local" binary directories. Its "~/bin" 
which would be "/root/bin", not writable to by a regular user.

Interestingly enough it also prints the following error after entering 
the user name:

"configuration error – unknown item 'ALWAYS_SET_PATH' (notify 
administrator)"

The "login" command which is in the "login" package in Debian, which is 
part of the "shadow" source package, does not understand the option.

It appears to me that sharing a configuration file like this is not such 
a good idea. However, it continues and I can still login.

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

I knew it has a *huge* amount of fine-grained controls, but I did not 
know off hand whether I can also specify what environment variables to 
take over, thank you for telling me. I think I will go that route. I 
intend to make sudo -i / sudo -s just always give SSH agent environment 
variables to the "root" shell on my laptop.

However I likely do that when I feel like it. Its holiday time for me 
currently. And I do feel comfortable enough with using the 
"ALWAYS_SET_PATH" option on my laptop for now.

Thanks,
-- 
Martin

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

[Theodore Y. Ts'o]

On Mon, Aug 06, 2018 at 10:24:43AM +0200, Martin Steigerwald wrote:
> 
> Thank you, Ted. This is the best explanation I saw so far. I accept it 
> for default.
>

An interesting question to consider is where would be the best place
to put this kind of information.  I learned it very on in my career,
and what is "obvious" to one person can be "obscure lore" to another.

It's probably too much tutorial information for the su man page, but
some kind of "system administrators tutorial/guide/handbook" might be
a great place for this kind of "so you want to create system
administration scripts as root --- what are best practices for
security/robustness/etc.".  For Debian systems, maybe contributing
something to The Debian Administrator's Handbook, at
https://debian-handbook.info?

I'm not sure what's the best place for Fedora/RedHat/Ubuntu system
administrators.

					- Ted

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

[Karel Zak]

On Mon, Aug 06, 2018 at 09:21:23AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Aug 06, 2018 at 10:24:43AM +0200, Martin Steigerwald wrote:
> > 
> > Thank you, Ted. This is the best explanation I saw so far. I accept it 
> > for default.
> >
> 
> An interesting question to consider is where would be the best place
> to put this kind of information.  I learned it very on in my career,
> and what is "obvious" to one person can be "obscure lore" to another.
> 
> It's probably too much tutorial information for the su man page, but

I don't see problem to add "SAFE ENVIRONMENT" to su(1), it's probably
place where the topic will be more visible than in some tutorial.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Bernhard Voelker]

On 08/06/2018 10:24 AM, Martin Steigerwald wrote:
> Theodore Y. Ts'o - 05.08.18, 17:05:
>> * The PATH might include the current directory, and so a script
> […]
>> So for that reason, it makes sense that a "sudo" or "su" command
>> should default to something safe.
> 
> Thank you, Ted. This is the best explanation I saw so far. I accept it 
> for default.
> 
> In my specific case I still do not see any big issue with that cause the 
> backup script runs on my laptop, the user I "su" from and "root" are 
> both users only I have access to.

If you have sanitized your PATH (and other variables) already outside, then
nothing prevents you from passing them into su or sudo.  E.g. the GNU coreutils
pass PATH and another variable for running the "root-only" testsuite:

  sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root

Can't you do something like that?

Have a nice day,
Berny

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

[Karel Zak]

On Sun, Aug 05, 2018 at 10:35:34AM +0200, Martin Steigerwald wrote:
> ownership preserved. However, for accessing the remote servers it needs
> access to the SSH agent running in the user session. The backup scripts 
> uses commands that are in "sbin" related directories.

This is common misunderstanding with su/sudo. 

su(1) creates a new *session* -- it means all the PAM stuff, all
logging, extra session parent process, etc. It's almost always
overkill to use such commands if all you need is a different UID.

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

setpriv(1) is the right choice and it's part of util-linux (at least
in upstream tree).

> Also… login.defs manpage from shadow project does not mention 
> "ALWAYS_SET_PATH", but manpage of su from util-linux does mention it. 
> And there does not appear to be a manpage about "login.defs" in "util-
> linux" package at all. (I found before that there appears to be a huge, 
> big mess about some things in "util-linux", some in "shadow" and some in 
> both).

"login.defs" is shared between many projects and tools. We have all
related options described in tool specific man pages -- for example in
su(1).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

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

[Martin Steigerwald]

Karel Zak - 06.08.18, 08:47:
> On Sun, Aug 05, 2018 at 10:35:34AM +0200, Martin Steigerwald wrote:
> > ownership preserved. However, for accessing the remote servers it
> > needs access to the SSH agent running in the user session. The
> > backup scripts uses commands that are in "sbin" related
> > directories.
> 
> This is common misunderstanding with su/sudo.
> 
> su(1) creates a new *session* -- it means all the PAM stuff, all
> logging, extra session parent process, etc. It's almost always
> overkill to use such commands if all you need is a different UID.

>From the viewpoint of the "loginctl" command from "systemd-logind" it 
does not. "loginctl" always displays one session, no matter how many 
"su" sessions I have open.

But I bet sessions are something different in different contexts.

> > 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".
> 
> setpriv(1) is the right choice and it's part of util-linux (at least
> in upstream tree).

Thanks for that hint. I now found that the "setpriv" binary package in 
Debian is from the "util-linux" source package.

However I do not see how "setpriv" would be appropriate for my use case. 
Just as "runuser" it can only be used as "root". It cannot be used by a 
regular user, as it can only drop privileges and does not ask for a 
password.

> > Also… login.defs manpage from shadow project does not mention
> > "ALWAYS_SET_PATH", but manpage of su from util-linux does mention
> > it.
> > And there does not appear to be a manpage about "login.defs" in
> > "util- linux" package at all. (I found before that there appears to
> > be a huge, big mess about some things in "util-linux", some in
> > "shadow" and some in both).
> 
> "login.defs" is shared between many projects and tools. We have all
> related options described in tool specific man pages -- for example in
> su(1).

Okay, noted. It of course adds to the confusion. And it feels 
inconsistent for it. 

And as I wrote in my reply to Ted´s mail: The "login" command from 
"shadow" project does not understand the "ALWAYS_SET_PATH" option the 
"su" command from "util-linux" project knows.

However I am not at all for "systemd"-ing this as well. But I wonder 
whether the current split of "shadow" and "util-linux" is all that 
beneficial. At least in that case I of using the "login.defs" file for 
both, I´d expect the tools to ignore unknown configuration options, but 
this has the risk to let a configuration error go unnoticed.

Thanks,
-- 
Martin