Util-Linux package development
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: util-linux@vger.kernel.org
Subject: Re: Debian´s change of "su" to the one in util-linux
Date: Mon, 06 Aug 2018 10:24:43 +0200	[thread overview]
Message-ID: <1642971.4ZBaquOb5i@merkaba> (raw)
In-Reply-To: <20180805150557.GC26138@thunk.org>

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



  reply	other threads:[~2018-08-06 10:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-05  8:35 Debian´s change of "su" to the one in util-linux Martin Steigerwald
2018-08-05 10:43 ` Dmitry V. Levin
2018-08-05 15:05 ` Theodore Y. Ts'o
2018-08-06  8:24   ` Martin Steigerwald [this message]
2018-08-06 13:21     ` Theodore Y. Ts'o
2018-08-06 14:43       ` Karel Zak
2018-08-06 15:56     ` Bernhard Voelker
2018-08-06  6:47 ` Karel Zak
2018-08-06  8:33   ` Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1642971.4ZBaquOb5i@merkaba \
    --to=martin@lichtvoll.de \
    --cc=tytso@mit.edu \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox