[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?
signature.asc
Description: OpenPGP digital signature
