* Debian´s change of "su" to the one in util-linux
@ 2018-08-05 8:35 Martin Steigerwald
2018-08-05 10:43 ` Dmitry V. Levin
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Martin Steigerwald @ 2018-08-05 8:35 UTC (permalink / raw)
To: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
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 6:47 ` Karel Zak
2 siblings, 0 replies; 9+ messages in thread
From: Dmitry V. Levin @ 2018-08-05 10:43 UTC (permalink / raw)
To: util-linux
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
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
2018-08-06 6:47 ` Karel Zak
2 siblings, 1 reply; 9+ messages in thread
From: Theodore Y. Ts'o @ 2018-08-05 15:05 UTC (permalink / raw)
To: Martin Steigerwald; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
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 6:47 ` Karel Zak
2018-08-06 8:33 ` Martin Steigerwald
2 siblings, 1 reply; 9+ messages in thread
From: Karel Zak @ 2018-08-06 6:47 UTC (permalink / raw)
To: Martin Steigerwald; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
2018-08-05 15:05 ` Theodore Y. Ts'o
@ 2018-08-06 8:24 ` Martin Steigerwald
2018-08-06 13:21 ` Theodore Y. Ts'o
2018-08-06 15:56 ` Bernhard Voelker
0 siblings, 2 replies; 9+ messages in thread
From: Martin Steigerwald @ 2018-08-06 8:24 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
2018-08-06 6:47 ` Karel Zak
@ 2018-08-06 8:33 ` Martin Steigerwald
0 siblings, 0 replies; 9+ messages in thread
From: Martin Steigerwald @ 2018-08-06 8:33 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
2018-08-06 8:24 ` Martin Steigerwald
@ 2018-08-06 13:21 ` Theodore Y. Ts'o
2018-08-06 14:43 ` Karel Zak
2018-08-06 15:56 ` Bernhard Voelker
1 sibling, 1 reply; 9+ messages in thread
From: Theodore Y. Ts'o @ 2018-08-06 13:21 UTC (permalink / raw)
To: Martin Steigerwald; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
2018-08-06 13:21 ` Theodore Y. Ts'o
@ 2018-08-06 14:43 ` Karel Zak
0 siblings, 0 replies; 9+ messages in thread
From: Karel Zak @ 2018-08-06 14:43 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: Martin Steigerwald, util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian´s change of "su" to the one in util-linux
2018-08-06 8:24 ` Martin Steigerwald
2018-08-06 13:21 ` Theodore Y. Ts'o
@ 2018-08-06 15:56 ` Bernhard Voelker
1 sibling, 0 replies; 9+ messages in thread
From: Bernhard Voelker @ 2018-08-06 15:56 UTC (permalink / raw)
To: Martin Steigerwald, Theodore Y. Ts'o; +Cc: util-linux
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-08-06 18:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).