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

[Michael Biebl]

[somehow messed up the CC list, s/pkg-gnome/pkg-systemd/]

Am 01.09.19 um 14:44 schrieb Alan Jenkins:
> On 01/09/2019 12:52, Michael Biebl wrote:
>> On 01.09.19 13:24, Alan Jenkins wrote:
>>> 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.
>> I guess gnustep-base-runtime explicitly needs to remove the existing
>> /etc/rc?.d/???gdomap symlinks on upgrades in preinst (possibly guarded
>> by a check which reads the old /etc/default/gdomap and tests if
>> ENABLED=NO) so they can be properly re-created (and disabled) by
>> "update-rc.d defaults-disabled"
>>
>> That said, I find the severity vastly exagerated, but that's just me.
> 
> Thanks.  In general I don't know what to do with the severity field
> :-).  I maybe used it once before, and that's it.
> 
> IMO this bug is release-relevant.  Then it should be "serious" or above.
> 
> #717773 points out that "unar" was installed by default, e.g. in Debian
> 7 Desktop. "unar" is not removed on upgrade, even after "apt
> autoremove".  Because "file-roller" still has "Suggests: unar".
> 
> #717773 was tagged "security", but the severity was "normal".  The
> current issue is slightly different to #717773, in the sense that it is
> a regression.
> 
> The above is post-hoc.  At the time, I just noticed that "reportbug
> --mode=standard" didn't offer me the "security" tag if I filed at
> severity "normal".  And gdomap doesn't run as root, so it's not a root
> bug ("critical").

I understand that it is unwanted if gdomap is running after the upgrade
when it wasn't before.
What I fail to see is the attach vector here.
Does a running gdomap service mean, the system is automatically
exploitable remotely? This information is missing.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190901/63db8620/attachment.sig>