Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Sam Hartman <hartmans@debian.org>]

>>>>> "Josue" == Josue Ortega <josue@debian.org> writes:

    Josue> On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
    >> What are the security implications of enabling this configure
    >> flag?
    Josue> Enabling this flag lets rpcbind to open random listening
    Josue> ports.  This would make firewalling very hard.  (Default
    Josue> behavior prior version 1.2.5)

    >> Why is it off by default?
    Josue> Upstream set it off by default since they claimed about
    Josue> customers complaining about this behavior and supposedly it's
    Josue> not widely used.  Check [1] for more details.

    Josue> Debian users running NIS services in Buster have reported
    Josue> breakage in their system due the lack of the remote call
    Josue> functionality.

For the stable release managers.
This change reverts  a security feature introduced upstream designed to
make rpcbind easier to firewall and reduce the attack surface of
rpcbind.

I'm reasonably familiar with portmap of old, but never really followed
the evolution from ONCRPC to TIRPC and don't remember all th obscure
aspects of NIS: it's been over 20 years since I used NIS.

In 10 minutes of googling I was not able to find what "remote calls" are
to really understand how NIS uses them and evaluate the security
implications.

At one level, yeah, Debian should support NIS if people want it.
And we have a regression.

At another level, it does look like this is security sensitive.  I think
using TIRPC for NFS is much more common than NIS.  Also, there are
configurations of NFS (for example NFSV4 secured by GSS-API) that are
vastly more secure than NIS.

It seems concerning to decrease the security of  rpcbind to the NIS
level with no option for the user to request the higher level of
security.

I do agree that fixing nis for stable is desirable.
My recommendation would be to:

1) Make this runtime configurable with an rpcbind command line option
rather than a compile time option.
The patche looks relatively simple to do that.

2) Document that option and its security implications better than I've
managed here.

--Sam