Bug#916753: Stop recommending s6

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#916753: Stop recommending s6

Laurent Bigonville-5
Package: apt-listbugs
Version: 0.1.26
Severity: normal

Hi,

I'm not too sure why you want to use s6-setuidgid (that requires an
extra package to be installed) when you have runuser tool that exists
precisely for this reason. runuser is available in the util-linux
package for quite some times already.

Kind regards,

Laurent Bigonville

https://salsa.debian.org/frx-guest/apt-listbugs/commit/60fe655dad963804290228a3886406016a3a82ee

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages apt-listbugs depends on:
ii  apt             1.8.0~alpha2
ii  ruby            1:2.5.1
ii  ruby-debian     0.3.9+b8
ii  ruby-gettext    3.2.9-1
ii  ruby-soap4r     2.0.5-4
ii  ruby-unicode    0.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
pn  s6               <none>

Versions of packages apt-listbugs suggests:
ii  firefox [www-browser]  64.0-1
ii  lynx [www-browser]     2.8.9rel.1-2
ii  reportbug              7.5.1
ii  sensible-utils         0.0.12
ii  xdg-utils              1.1.3-1

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#916753: Stop recommending s6

Laurent Bigonville-5
Le 19/12/18 à 00:28, Francesco Poli a écrit :

> On Tue, 18 Dec 2018 10:18:56 +0100 Laurent Bigonville wrote:
>
> [...]
>> Hi,
> Hello Laurent,
> thanks for asking the question and suggesting an alternative to s6.
>
>> I'm not too sure why you want to use s6-setuidgid (that requires an
>> extra package to be installed) when you have runuser tool that exists
>> precisely for this reason. runuser is available in the util-linux
>> package for quite some times already.
> The fact is that, AFAIK, runuser seems to be equivalent to su, which is
> not fit to *drop* root privileges (see the [web page] cited in
> the commit).
>
> [web page]:<https://jdebp.eu/FGA/dont-abuse-su-for-dropping-privileges.html>

I can agree that su might not the correct way of doing this mainly
because the su pam service file is doing historically a lot of things.

Otoh, runuser pam service is doing the strict minimum on purpose (ie
setting the limits based on the configuration and cleaning the kernel
keyring).

And even if you think that runuser shouldn't be used, I still think that
apt-listbugs shouldn't pull s6 and what you are trying to do here can
perfectly be done in pure ruby without the call to an external program

Reply | Threaded
Open this post in threaded view
|

Bug#916753: Stop recommending s6

Francesco Poli (wintermute)
On Thu, 20 Dec 2018 11:46:55 +0100 Laurent Bigonville wrote:

[...]
> Otoh, runuser pam service is doing the strict minimum on purpose (ie
> setting the limits based on the configuration and cleaning the kernel
> keyring).

But I am under the impression that it does not *permanently* drop root
privileges.

>
> And even if you think that runuser shouldn't be used, I still think that
> apt-listbugs shouldn't pull s6 and what you are trying to do here can
> perfectly be done in pure ruby without the call to an external program

Why reinventing the wheel in pure Ruby, when there are little DFSG-free
programs which are designed to drop root privileges, are developed by
people more knowledgeable than me about this topic, are tested and
already packaged for Debian?


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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#916753: Stop recommending s6

Laurent Bigonville-5
Le 20/12/18 à 23:53, Francesco Poli a écrit :
On Thu, 20 Dec 2018 11:46:55 +0100 Laurent Bigonville wrote:

[...]
Otoh, runuser pam service is doing the strict minimum on purpose (ie 
setting the limits based on the configuration and cleaning the kernel 
keyring).
But I am under the impression that it does not *permanently* drop root
privileges.

What makes you think that?

bigon@fornost:~$ sudo runuser -u bigon /bin/bash -- -c "cat /proc/$$/status|grep -E '[G|U]id'"
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000

http://man7.org/linux/man-pages/man5/proc.5.html says that UID and GID are:

              * Uid, Gid: Real, effective, saved set, and filesystem UIDs
                (GIDs).

So bash is running as my UID/GID again.

You indeed have runuser still running as root, that's true:

root      8909  0.0  0.0  14856  4388 pts/0    S    09:38   0:00 sudo runuser -u bigon /bin/bash
root      8910  0.0  0.0  14180  3444 pts/0    S    09:38   0:00 runuser -u bigon /bin/bash
bigon     8911  0.0  0.0   8044  4896 pts/0    S    09:38   0:00 /bin/bash

But I don't see this being a problem, but I'm maybe overlooking something here?

I tested quickly by replacing s6-setuidgid by runuser and it's working fine.

The only problems can see here is the fact that running the browser (ie firefox) directly started by user or started after switching to root and then back to the user might not produce the same result (environments being different, SELinux context not being the expected one,...) but AFAICS this might also happen with s6-setuidgid.

Anyway, I installed s6 on my machine to give a try at the current implementation and it's not working, I get the following error:

s6-envuidgid: fatal: unable to get supplementary groups for bigon: No such file or directory

Reply | Threaded
Open this post in threaded view
|

Bug#916753: Stop recommending s6

Francesco Poli (wintermute)
On Fri, 21 Dec 2018 10:58:59 +0100 Laurent Bigonville wrote:

> Le 20/12/18 à 23:53, Francesco Poli a écrit :
> > On Thu, 20 Dec 2018 11:46:55 +0100 Laurent Bigonville wrote:
> >
> > [...]
> >> Otoh, runuser pam service is doing the strict minimum on purpose (ie
> >> setting the limits based on the configuration and cleaning the kernel
> >> keyring).
> > But I am under the impression that it does not *permanently* drop root
> > privileges.
>
> What makes you think that?
>
> bigon@fornost:~$ sudo runuser -u bigon /bin/bash -- -c "cat /proc/$$/status|grep -E '[G|U]id'"
> Uid: 1000 1000 1000 1000
> Gid: 1000 1000 1000 1000
>
> http://man7.org/linux/man-pages/man5/proc.5.html says that UID and GID are:
>
>                */Uid/,/Gid/: Real, effective, saved set, and filesystem UIDs
>                  (GIDs).
>
> So bash is running as my UID/GID again.
Well, this puzzles me.

  $ su -
  Password:
  # su - $(logname) -c /bin/bash -c 'cat /proc/$$/status|grep "[GU]id"'
  Uid:    1000    1000    1000    1000
  Gid:    1000    1000    1000    1000
  # runuser -u $(logname) /bin/bash -- -c 'cat /proc/$$/status|grep "[GU]id"'
  Uid:    1000    1000    1000    1000
  Gid:    1000    1000    1000    1000
  # s6-setuidgid $(logname)  /bin/bash -c 'cat /proc/$$/status|grep "[GU]id"'
  Uid:    1000    1000    1000    1000
  Gid:    1000    1000    1000    1000

I thought the three commands were more different in this respect...

>
> You indeed have runuser still running as root, that's true:
[...]
> But I don't see this being a problem, but I'm maybe overlooking
> something here?

I am not sure, but maybe this is the key difference.
The previously cited [web page] states:

[...]
| The su command
[...]
| is a mechanism for adding privileges
[...]
| If, for example, one is user A at an interactive shell and one runs
| su B then one has two shells available, one running under the aegis
| of user A and one running under the aegis of user B, and one has the
| privileges of both users at one's fingertips. (With job control,
| switching between the two is a matter of the suspend and fg commands.)
[...]

The subsequent discussion on PAM-enabled su also stresses the
difference between forking and changing privileges for the child
process only (while keeping the parent process around, with the original
privileges) and chain loading a new command, after irreversibly dropping
root privileges.

[web page]: <https://jdebp.eu/FGA/dont-abuse-su-for-dropping-privileges.html>

>
> I tested quickly by replacing s6-setuidgid by runuser and it's working fine.
>
> The only problems can see here is the fact that running the browser (ie
> firefox) directly started by user or started after switching to root and
> then back to the user might not produce the same result (environments
> being different, SELinux context not being the expected one,...) but
> AFAICS this might also happen with s6-setuidgid.

Yes, I would like to have a command that works like s6-setuidgid (takes
a username as first argument and a command as subsequent arguments,
irreversibly drops root privileges to impersonate the given user), but
chain loads the given user's login shell (as recorded
in /etc/passwd or equivalent database), and runs the given command
inside the login shell with all the environment that the user would get
on a normal login.
Then, it would be fantastic, if there were a convenient mechanism for
letting the DISPLAY environment variable be set so that the above
mentioned login shell could talk to the user's running X server, if any.

I have not yet found a command with these features, unfortunately.
I hope there will be one in the future.

>
> Anyway, I installed s6 on my machine to give a try at the current
> implementation and it's not working, I get the following error:
>
> s6-envuidgid: fatal: unable to get supplementary groups for bigon: No
> such file or directory

Do you mean that the current version of apt-listbugs fails to work for
you?
If this is the case, sorry about that: I'll try and investigate the
issue, but please file a separate bug report and explain what you did
and what went wrong, because I am not sure I understand how you got the
above-mentioned error message.

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

attachment0 (849 bytes) Download Attachment