Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".

When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap".  I did not see this server on Debian 9.
"gdomap" is not wanted.  It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]

[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773

The problem is due to this code change:

"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f

Salvatore Bonaccorso analyzed this for me:

> Install a fresh stretch installation and install gnustep-base-runtime
> in it. gdomap is not started by default, because gdomap init honours
> the ENABLED=no setting in /etc/default/gdomap. Now update the host to
> buster.
>
> During this update /etc/default/gdomap is updated according to the
> above. Unless the admin has modified it, where then it will be
> noticed and admin asked for a decision. As formerly the init was
> enabled, and the code to handle the ENABLED setting is removed this
> might be the problem. The postinst calls update-rc.d gdomap
> defaults-disabled [...]

"update-rc.d" does not do anything in this case.  The man page says

> If any files named /etc/rcrunlevel.d/[SK]??name already exist then
> update-rc.d does nothing.  The program was written this way so that
> it will never change an existing configuration, which may have been
> customized by the system administrator.  The program will only  
> install links if none are present, i.e., if it appears that the 
> service has never been installed before.

It is unfortunate that "Policy 9.3.3.1" does not have an explicit
warning about this potential security problem.

So this is a problem with upgrades.  It does not happen on a fresh
install of Debian 10.

Salvatore also suggested

> I think it's best handled though in a bugreport accordngly, and once
> fixed in unstable, to schedule a fix as well via a buster point
> release.

    $ sudo netstat -l -p
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
    ...        
    udp        0      0 0.0.0.0:gdomap          0.0.0.0:*                           57/gdomap

    $ ps aux | grep gdomap
    nobody      57  0.0  0.0   2736  2052 ?        Ss   11:16   0:00 /usr/bin/gdomap -I /var/run/gdomap.pid -p -j /var/run/gdomap

    $ dpkg-query -S gdomap
    gnustep-base-runtime: /usr/share/man/man8/gdomap.8.gz
    gnustep-base-runtime: /etc/default/gdomap
    gnustep-base-runtime: /usr/bin/gdomap
    gnustep-base-runtime: /etc/init.d/gdomap


[Report sent from a systemd-nspawn container, which I used to reproduce the issue]

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.9-200.fc30.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnustep-base-runtime depends on:
ii  gnustep-base-common  1.26.0-4
ii  init-system-helpers  1.56+nmu1
ii  libc6                2.28-10
ii  libgcc1              1:8.3.0-6
ii  libgnustep-base1.26  1.26.0-4
ii  libobjc4             8.3.0-6
ii  lsb-base             10.2019051400

gnustep-base-runtime recommends no packages.

gnustep-base-runtime suggests no packages.

-- no debconf information