Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

Control: tags -1 - moreinfo


On Thu, 14 Feb 2019 19:28:29 + Simon McVittie wrote:

> On Sat, 09 Feb 2019 at 23:26:53 +0100, Francesco Poli wrote:
> > On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:
> > > I guess I already mentioned the two alternatives (runuser/setpriv).
> > [...]
> > 
> > Maybe setpriv is equivalent to s6-setuidgid.
> > If this is the case, it can be used as an alternative to s6-setuidgid.
> 
[...]
> Running `setpriv --reuid NAME --init-groups PROGRAM ARGS` appears to be
> equivalent to `s6-setuidgid NAME PROGRAM ARGS`.

OK, thanks for the explanation.
I'll try to find some time to experiment and apply this change to
apt-listbugs. Since buster is already in soft freeze, the modification
will probably have to be meant for buster+1 ...

[...]
> > I would like some insight especially on [message #30], regarding the
> > fact that runuser does something basically equivalent to what su does,
> > and thus seems to be unfit to irreversibly drop root privileges
> 
> The major difference between {setpriv,s6-setuidgid} and runuser is that
> runuser, like su, sets up a new PAM session and re-initializes some
> standard environment variables.
> 
> Also like su, if run with -l, it also tries to behave like a login shell
> (clears more environment variables, changes to the target user's home
> directory, etc.) and runs a different PAM stack (which registers with
> systemd-logind, if installed, as a new login session).
> 
> However, runuser is not setuid (unlike su), so it cannot increase
> privileges, only drop them. The only thing it *can* do is to drop root
> privileges; so if you consider it to be unfit to do that for some reason,
> it would have no purpose at all.

As far as I understand it (after reading the [web page] cited in
the commit where I introduce the s6 recommendation into apt-listbugs),
the problem with su and similar programs is not that they cannot drop
root privileges, but that they cannot do so irreversibly.

[web page]: 

However, this is not especially important now, since we are talking
about replacing s6-setuidgid with setpriv...

[...]
> > and
> > regarding my search for a command that works like s6-setuidgid, but
> > runs the given command inside the user's login shell (with all the
> > environment that the user would get on a normal login).
> 
> As stated, this isn't really well-defined. Whether and how this is
> possible depends what you mean by "a normal login". The execution
> environment the user would get from login(1) as invoked by getty(8),
> from a display manager like xdm, and from sshd are all different (they
> invoke different PAM stacks); and that's before you've even entered
> any shells.
[...]

Wow, thanks a lot for the very long and detailed explanations!
They were an interesting read that clarified some points.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpkexsv1GzgQ.pgp
Description: PGP signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Simon McVittie]

On Sat, 09 Feb 2019 at 23:26:53 +0100, Francesco Poli wrote:
> On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:
> > I guess I already mentioned the two alternatives (runuser/setpriv).
> [...]
> 
> Maybe setpriv is equivalent to s6-setuidgid.
> If this is the case, it can be used as an alternative to s6-setuidgid.

As far as I can tell, s6-setuidgid sets the uid, primary gid and
supplementary group list with setuid(), setgid() and setgroups() (by
a somewhat convoluted route involving putting them in the environment
with s6-envuidgid and reading them back out in s6-applyuidgid, presumably
out of a preference for small composable tools), and doesn't do anything
else of interest (for example resetting HOME or LOGNAME to reflect the
new identity, which it should perhaps do).

Running `setpriv --reuid NAME --init-groups PROGRAM ARGS` appears to be
equivalent to `s6-setuidgid NAME PROGRAM ARGS`. This is because on Linux
(and hopefully the non-Linux ports too), setuid(x) called by a privileged
process is documented to be equivalent to setresuid(x, x, x), which
is exactly what setpriv --reuid ends up doing; and setpriv --init-groups
takes the `struct passwd` for the NAME given to --reuid (or --ruid),
and sets the primary gid and supplementary group list based on it,
just like the combination of s6-envuidgid and s6-applyuidgid.

If you don't consider the current use of s6-setuidgid to be a bug, then
using setpriv would have an equivalent effect without a non-Essential
dependency, closing Bug #921819 and the very similar bug #916753.
Anything beyond that (for example altering DISPLAY, HOME, LOGNAME, etc.
to get an environment more closely resembling the target user's login
shell) is a separate request for enhancement that is not solved by
s6-setuidgid either, so please don't let the perfect be the enemy of
the good here.

> I would like some insight especially on [message #30], regarding the
> fact that runuser does something basically equivalent to what su does,
> and thus seems to be unfit to irreversibly drop root privileges

The major difference between {setpriv,s6-setuidgid} and runuser is that
runuser, like su, sets up a new PAM session and re-initializes some
standard environment variables.

Also like su, if run with -l, it also tries to behave like a login shell
(clears more environment variables, changes to the target user's home
directory, etc.) and runs a different PAM stack (which registers with
systemd-logind, if installed, as a new login session).

However, runuser is not setuid (unlike su), so it cannot increase
privileges, only drop them. The only thing it *can* do is to drop root
privileges; so if you consider it to be unfit to do that for some reason,
it would have no purpose at all. I assume the maintainers of util-linux
are not in the habit of adding tools that have no purpose.

> and
> regarding my search for a command that works like s6-setuidgid, but
> runs the given command inside the user's login shell (with all the
> environment that the user would get on a normal login).

As stated, this isn't really well-defined. Whether and how this is
possible depends what you mean by "a normal login". The execution
environment the user would get from login(1) as invoked by getty(8),
from a display manager like xdm, and from sshd are all different (they
invoke different PAM stacks); and that's before you've even entered
any shells.

Running a given command in a user's login shell also suffers from the fact
that you don't actually know what the user's login shell does. It isn't
guaranteed to be a POSIX shell, or a Bourne-compatible shell, or in any
way suitable for non-interactive use, and it isn't guaranteed to take
the same command-line arguments as dash and bash.

> But I would like to have a command that runs a given command inside the
> regular user's login environment, as I said above.
> Do you know one such command?

The tl;dr answer is "no". The slightly longer answer is "it's
complicated".

If your design relies on being able to do this, it might be a good idea
to rethink aspects of your design. For instance, instead of bending
over backwards to run a web browser as the invoking user, it might be
reasonable to print a file:/// URL to the terminal, and hope the invoking
user has a terminal in which they can Ctrl+click URLs? Recent versions
of some terminals even have an escape sequence to mark arbitrary text
as a clickable URL, as used by `ls --hyperlink`.

The long answer starts with: this is not really how it works. You can't
unilaterally move a child process from your own execution environment
into a logged-in user's execution environment: whatever you do, it will
inherit the inheritable aspects of its execution environment from you,
not from the user.

Historically, the inheritable aspects of the execution environment were
sufficiently well-known and sufficiently few in number (for instance
credentials, environment variables and working directory) that you could
get away with resetting 

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

On Wed, 13 Feb 2019 19:39:25 +0100 Michael Biebl wrote:

> Am 09.02.19 um 23:26 schrieb Francesco Poli:
[...]
> > regarding my search for a command that works like s6-setuidgid, but
> > runs the given command inside the user's login shell (with all the
> > environment that the user would get on a normal login).
> 
> Aren't those conflicting requirements?
> On the one hand you want a full login shell, which typically involves
> PAM. On the other hand you don't want PAM involved.

Maybe you are right, I haven't yet searched for this hypothetical tool
too diligently...

[...]
> > Maybe setpriv is equivalent to s6-setuidgid.
> > If this is the case, it can be used as an alternative to s6-setuidgid.
> 
> setpriv should do pretty much the same as s6-setuidgid, with the benefit
> of not requiring an exotic package being installed.
> 
> > But I would like to have a command that runs a given command inside the
> > regular user's login environment, as I said above.
> > Do you know one such command?
> 
> What exactly do you mean by "user's login environment"?

I am dreaming about the possibility to find the environment variables
that the impersonated regular user sets in his/her own login shell
initialization files, to find his/her favorite web browser (via
sensible-browser or xdg-open) and, perhaps, connecting to the X server
running his/her graphical session (if any) and launching the web
browser (say, firefox) attaching to the running instance (if any).

Maybe all this is too good to be possible, but still...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgphu3CPiNwiq.pgp
Description: PGP signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Michael Biebl]

Am 09.02.19 um 23:26 schrieb Francesco Poli:
> On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:
> 
>> Hi
>>
>> Am 09.02.19 um 10:39 schrieb Francesco Poli:
>>
>>> Could you please do me a favor?
>>> I would like you to read bug [#916753] log and then tell me what you
>>> think. Your insight might be useful to find a better solution.
>>
>> What kind of input do you need?
> 
> I would like some insight especially on [message #30], regarding the
> fact that runuser does something basically equivalent to what su does,
> and thus seems to be unfit to irreversibly drop root privileges, and
> regarding my search for a command that works like s6-setuidgid, but
> runs the given command inside the user's login shell (with all the
> environment that the user would get on a normal login).

Aren't those conflicting requirements?
On the one hand you want a full login shell, which typically involves
PAM. On the other hand you don't want PAM involved.

> [message #30]: 
> 
>> I guess I already mentioned the two alternatives (runuser/setpriv).
> [...]
> 
> Maybe setpriv is equivalent to s6-setuidgid.
> If this is the case, it can be used as an alternative to s6-setuidgid.

setpriv should do pretty much the same as s6-setuidgid, with the benefit
of not requiring an exotic package being installed.

> But I would like to have a command that runs a given command inside the
> regular user's login environment, as I said above.
> Do you know one such command?

What exactly do you mean by "user's login environment"?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:

> Hi
> 
> Am 09.02.19 um 10:39 schrieb Francesco Poli:
> 
> > Could you please do me a favor?
> > I would like you to read bug [#916753] log and then tell me what you
> > think. Your insight might be useful to find a better solution.
> 
> What kind of input do you need?

I would like some insight especially on [message #30], regarding the
fact that runuser does something basically equivalent to what su does,
and thus seems to be unfit to irreversibly drop root privileges, and
regarding my search for a command that works like s6-setuidgid, but
runs the given command inside the user's login shell (with all the
environment that the user would get on a normal login).

[message #30]: 

> I guess I already mentioned the two alternatives (runuser/setpriv).
[...]

Maybe setpriv is equivalent to s6-setuidgid.
If this is the case, it can be used as an alternative to s6-setuidgid.

But I would like to have a command that runs a given command inside the
regular user's login environment, as I said above.
Do you know one such command?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpZOMog3Kfx0.pgp
Description: PGP signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Michael Biebl]

Hi

Am 09.02.19 um 10:39 schrieb Francesco Poli:

> Could you please do me a favor?
> I would like you to read bug [#916753] log and then tell me what you
> think. Your insight might be useful to find a better solution.

What kind of input do you need?
I guess I already mentioned the two alternatives (runuser/setpriv).
Depending on your needs (w or w/o PAM session), they both should do fine
and would avoid needing this dependency on s6-setuidgid.

Michael




signature.asc
Description: OpenPGP digital signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

Control: tags -1 + moreinfo
Control: severity -1 wishlist


On Sat, 09 Feb 2019 07:01:29 +0100 Michael Biebl wrote:

[...]
>
> Hi,

Hello Michael,
thanks for your bug report.

> 
> I was rather suprised to have the whole suite of s6 supervision
> binaries installed on my system.
> Turns out the s6 package was installed by apt-listbugs via Recommends
[...]

Yes, this is a recently added recommendation.
Since it's just a recommendation (and not a dependency), you can safely
purge the s6 package, if you do not want it on your system.
But I am sure this is well known to you...

> It looks to me, that all the functionality that you need is
> provided by either setpriv or runuser.
> Both those tools are shipped by util-linux and thus available on every
> system, as util-linux is marked as essential.
> Please consider dropping the dependency on s6 / s6-setuidgid an use
> either setpriv or runuser (it's not entirely clear if you want a PAM
> session or not in your case. If not, the former tool is what you want).

OK, this is becoming a recurring request.
Maybe I should add an entry to /usr/share/doc/apt-listbugs/FAQ.md.gz ...

Could you please do me a favor?
I would like you to read bug [#916753] log and then tell me what you
think. Your insight might be useful to find a better solution.

[#916753]: 

Please let me know.
Thanks for your time and patience.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpxqtUNX4Htk.pgp
Description: PGP signature

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Michael Biebl]

Package: apt-listbugs
Version: 0.1.28
Severity: normal

Hi,

I was rather suprised to have the whole suite of s6 supervision
binaries installed on my system.
Turns out the s6 package was installed by apt-listbugs via Recommends
[1]. It looks to me, that all the functionality that you need is
provided by either setpriv or runuser.
Both those tools are shipped by util-linux and thus available on every
system, as util-linux is marked as essential.
Please consider dropping the dependency on s6 / s6-setuidgid an use
either setpriv or runuser (it's not entirely clear if you want a PAM
session or not in your case. If not, the former tool is what you want).

Regards,
Michael



[1] 
https://salsa.debian.org/frx-guest/apt-listbugs/commit/60fe655dad963804290228a3886406016a3a82ee
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 1.8.0~rc2
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-1
ii  s6   2.7.2.2-3

Versions of packages apt-listbugs suggests:
ii  epiphany-browser [www-browser]  3.30.3-1
ii  firefox [www-browser]   65.0-1
ii  google-chrome-stable [www-browser]  72.0.3626.96-1
ii  lynx [www-browser]  2.8.9rel.1-3
ii  reportbug   7.5.2
ii  sensible-utils  0.0.12
ii  w3m [www-browser]   0.5.3-37
ii  xdg-utils   1.1.3-1

-- no debconf information