I would like to ask you a question regarding the new random UDP port
in rpcbind 0.2.3.
In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
rpcbind.service, then I do netstat
udp 0 0 0.0.0.0:111 0.0.0.0:*
10408/rpcbind
udp 0 0 0.0.0.0:831 0.0.0.0:*
10408/rpcbind
udp6 0 0 :::111 :::*
10408/rpcbind
udp6 0 0 :::831 :::*
10408/rpcbind
The rpcbind does not only listen on port 111 but also on a random udp
port "831" in this case, this port is changed every time the rpcbind
service retstarts. And it listens on 0.0.0.0 so it opens a hole on
security. Could you please let me know what this port is for and is
there any way to avoid that like force it listen on a internal
interface rather than on any interfaces like that? I do not see the
random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
from systemd so "-h" option is invalid as the man page says:
-h Specify specific IP addresses to bind to for UDP requests.
This option may be specified multiple times and can be used to
restrict the interfaces rpcbind will respond to. Note that when
rpcbind is controlled via sys-
temd's socket activation, the -h option is ignored. In
this case, you need to edit the ListenStream and ListenDgram
definitions in /usr/lib/systemd/system/rpcbind.socket instead.
Thanks a lot,
Brs,
Naruto
Hello,
Just would like to add for more information, when I start rpcbind
normally, not via systemd, the random UDP is still opened
Could you please share any ideas on this?
Brs,
Bao
On 27 January 2018 at 19:50, Naruto Nguyen <[email protected]> wrote:
> I would like to ask you a question regarding the new random UDP port
> in rpcbind 0.2.3.
>
> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
> rpcbind.service, then I do netstat
>
> udp 0 0 0.0.0.0:111 0.0.0.0:*
> 10408/rpcbind
> udp 0 0 0.0.0.0:831 0.0.0.0:*
> 10408/rpcbind
> udp6 0 0 :::111 :::*
> 10408/rpcbind
> udp6 0 0 :::831 :::*
> 10408/rpcbind
>
> The rpcbind does not only listen on port 111 but also on a random udp
> port "831" in this case, this port is changed every time the rpcbind
> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
> security. Could you please let me know what this port is for and is
> there any way to avoid that like force it listen on a internal
> interface rather than on any interfaces like that? I do not see the
> random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
> from systemd so "-h" option is invalid as the man page says:
>
>
> -h Specify specific IP addresses to bind to for UDP requests.
> This option may be specified multiple times and can be used to
> restrict the interfaces rpcbind will respond to. Note that when
> rpcbind is controlled via sys-
> temd's socket activation, the -h option is ignored. In
> this case, you need to edit the ListenStream and ListenDgram
> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>
> Thanks a lot,
> Brs,
> Naruto
On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
> Hello,
>
> Just would like to add for more information, when I start rpcbind
> normally, not via systemd, the random UDP is still opened
>
> Could you please share any ideas on this?
The bound UDP socket is used for remote calls... Where rpcbind
is asked to make a remote RPC for another caller...
Antiquated? yes.. but harmless.
steved.
>
> Brs,
> Bao
>
> On 27 January 2018 at 19:50, Naruto Nguyen <[email protected]> wrote:
>> I would like to ask you a question regarding the new random UDP port
>> in rpcbind 0.2.3.
>>
>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>> rpcbind.service, then I do netstat
>>
>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>> 10408/rpcbind
>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>> 10408/rpcbind
>> udp6 0 0 :::111 :::*
>> 10408/rpcbind
>> udp6 0 0 :::831 :::*
>> 10408/rpcbind
>>
>> The rpcbind does not only listen on port 111 but also on a random udp
>> port "831" in this case, this port is changed every time the rpcbind
>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
>> security. Could you please let me know what this port is for and is
>> there any way to avoid that like force it listen on a internal
>> interface rather than on any interfaces like that? I do not see the
>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
>> from systemd so "-h" option is invalid as the man page says:
>>
>>
>> -h Specify specific IP addresses to bind to for UDP requests.
>> This option may be specified multiple times and can be used to
>> restrict the interfaces rpcbind will respond to. Note that when
>> rpcbind is controlled via sys-
>> temd's socket activation, the -h option is ignored. In
>> this case, you need to edit the ListenStream and ListenDgram
>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>
>> Thanks a lot,
>> Brs,
>> Naruto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> wrote:
>=20
>=20
>=20
> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
>> Hello,
>>=20
>> Just would like to add for more information, when I start rpcbind
>> normally, not via systemd, the random UDP is still opened
>>=20
>> Could you please share any ideas on this?
> The bound UDP socket is used for remote calls... Where rpcbind
> is asked to make a remote RPC for another caller...=20
>=20
> Antiquated? yes.. but harmless.
Not quite harmless. It can occupy a privileged port that belongs
to a real service.
We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
it doesn't have to hold onto that port indefinitely. It should
be able to bind to an outgoing privileged port whenever it needs
one.
> steved.
>=20
>>=20
>> Brs,
>> Bao
>>=20
>> On 27 January 2018 at 19:50, Naruto Nguyen =
<[email protected]> wrote:
>>> I would like to ask you a question regarding the new random UDP port
>>> in rpcbind 0.2.3.
>>>=20
>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>>> rpcbind.service, then I do netstat
>>>=20
>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>> 10408/rpcbind
>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>>> 10408/rpcbind
>>> udp6 0 0 :::111 :::*
>>> 10408/rpcbind
>>> udp6 0 0 :::831 :::*
>>> 10408/rpcbind
>>>=20
>>> The rpcbind does not only listen on port 111 but also on a random =
udp
>>> port "831" in this case, this port is changed every time the rpcbind
>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
>>> security. Could you please let me know what this port is for and is
>>> there any way to avoid that like force it listen on a internal
>>> interface rather than on any interfaces like that? I do not see the
>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is =
started
>>> from systemd so "-h" option is invalid as the man page says:
>>>=20
>>>=20
>>> -h Specify specific IP addresses to bind to for UDP requests.
>>> This option may be specified multiple times and can be used to
>>> restrict the interfaces rpcbind will respond to. Note that when
>>> rpcbind is controlled via sys-
>>> temd's socket activation, the -h option is ignored. In
>>> this case, you need to edit the ListenStream and ListenDgram
>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>>=20
>>> Thanks a lot,
>>> Brs,
>>> Naruto
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
On 01/31/2018 02:43 PM, Chuck Lever wrote:
>
>
>> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> wrote:
>>
>>
>>
>> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
>>> Hello,
>>>
>>> Just would like to add for more information, when I start rpcbind
>>> normally, not via systemd, the random UDP is still opened
>>>
>>> Could you please share any ideas on this?
>> The bound UDP socket is used for remote calls... Where rpcbind
>> is asked to make a remote RPC for another caller...
>>
>> Antiquated? yes.. but harmless.
>
> Not quite harmless. It can occupy a privileged port that belongs
> to a real service.
fair enough...
>
> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
> it doesn't have to hold onto that port indefinitely. It should
> be able to bind to an outgoing privileged port whenever it needs
> one.
Or we just avoid know ports like sm-notify does.
steved.
>
>
>> steved.
>>
>>>
>>> Brs,
>>> Bao
>>>
>>> On 27 January 2018 at 19:50, Naruto Nguyen <[email protected]> wrote:
>>>> I would like to ask you a question regarding the new random UDP port
>>>> in rpcbind 0.2.3.
>>>>
>>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>>>> rpcbind.service, then I do netstat
>>>>
>>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>>> 10408/rpcbind
>>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>>>> 10408/rpcbind
>>>> udp6 0 0 :::111 :::*
>>>> 10408/rpcbind
>>>> udp6 0 0 :::831 :::*
>>>> 10408/rpcbind
>>>>
>>>> The rpcbind does not only listen on port 111 but also on a random udp
>>>> port "831" in this case, this port is changed every time the rpcbind
>>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
>>>> security. Could you please let me know what this port is for and is
>>>> there any way to avoid that like force it listen on a internal
>>>> interface rather than on any interfaces like that? I do not see the
>>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
>>>> from systemd so "-h" option is invalid as the man page says:
>>>>
>>>>
>>>> -h Specify specific IP addresses to bind to for UDP requests.
>>>> This option may be specified multiple times and can be used to
>>>> restrict the interfaces rpcbind will respond to. Note that when
>>>> rpcbind is controlled via sys-
>>>> temd's socket activation, the -h option is ignored. In
>>>> this case, you need to edit the ListenStream and ListenDgram
>>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>>>
>>>> Thanks a lot,
>>>> Brs,
>>>> Naruto
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
>
>
>
> On Jan 31, 2018, at 2:57 PM, Steve Dickson <[email protected]> wrote:
>=20
>=20
>=20
> On 01/31/2018 02:43 PM, Chuck Lever wrote:
>>=20
>>=20
>>> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> =
wrote:
>>>=20
>>>=20
>>>=20
>>> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
>>>> Hello,
>>>>=20
>>>> Just would like to add for more information, when I start rpcbind
>>>> normally, not via systemd, the random UDP is still opened
>>>>=20
>>>> Could you please share any ideas on this?
>>> The bound UDP socket is used for remote calls... Where rpcbind
>>> is asked to make a remote RPC for another caller...=20
>>>=20
>>> Antiquated? yes.. but harmless.
>>=20
>> Not quite harmless. It can occupy a privileged port that belongs
>> to a real service.
> fair enough...=20
>=20
>>=20
>> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
>> it doesn't have to hold onto that port indefinitely. It should
>> be able to bind to an outgoing privileged port whenever it needs
>> one.
> Or we just avoid know ports like sm-notify does.
statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead
of what it does now, IMO.
Note that in both of these cases, that long-lived port is never going
to be used, going forward:=20
- no one uses the rpcbind port-forward service that I know of
- NLM is going out of style
If we can make these two cases on-demand instead, so much the better,
I say. As Mr. Talpey pointed out recently, the only long-lived
privileged ports we should see on Linux are well-known service
listeners, not outgoing ports.
A fix for rpcbind might be to add a cmd-line flag to enable the
rpcbind forwarding service, and have the service default to disabled.
I'm not sure why rpcbind would list an outgoing port in it's portmap
menu. Are you sure that this is the forwarding reflector port?
> steved.
>=20
>>=20
>>=20
>>> steved.
>>>=20
>>>>=20
>>>> Brs,
>>>> Bao
>>>>=20
>>>> On 27 January 2018 at 19:50, Naruto Nguyen =
<[email protected]> wrote:
>>>>> I would like to ask you a question regarding the new random UDP =
port
>>>>> in rpcbind 0.2.3.
>>>>>=20
>>>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>>>>> rpcbind.service, then I do netstat
>>>>>=20
>>>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>>>> 10408/rpcbind
>>>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>>>>> 10408/rpcbind
>>>>> udp6 0 0 :::111 :::*
>>>>> 10408/rpcbind
>>>>> udp6 0 0 :::831 :::*
>>>>> 10408/rpcbind
>>>>>=20
>>>>> The rpcbind does not only listen on port 111 but also on a random =
udp
>>>>> port "831" in this case, this port is changed every time the =
rpcbind
>>>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
>>>>> security. Could you please let me know what this port is for and =
is
>>>>> there any way to avoid that like force it listen on a internal
>>>>> interface rather than on any interfaces like that? I do not see =
the
>>>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is =
started
>>>>> from systemd so "-h" option is invalid as the man page says:
>>>>>=20
>>>>>=20
>>>>> -h Specify specific IP addresses to bind to for UDP =
requests.
>>>>> This option may be specified multiple times and can be used to
>>>>> restrict the interfaces rpcbind will respond to. Note that when
>>>>> rpcbind is controlled via sys-
>>>>> temd's socket activation, the -h option is ignored. In
>>>>> this case, you need to edit the ListenStream and ListenDgram
>>>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>>>>=20
>>>>> Thanks a lot,
>>>>> Brs,
>>>>> Naruto
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe =
linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>=20
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>=20
>> --
>> Chuck Lever
--
Chuck Lever
On Wed, 31 Jan 2018, Chuck Lever wrote:
>
>
> > On Jan 31, 2018, at 2:57 PM, Steve Dickson <[email protected]> wrote:
> >
> >
> >
> > On 01/31/2018 02:43 PM, Chuck Lever wrote:
> >>
> >>
> >>> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> wrote:
> >>>
> >>>
> >>>
> >>> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
> >>>> Hello,
> >>>>
> >>>> Just would like to add for more information, when I start rpcbind
> >>>> normally, not via systemd, the random UDP is still opened
> >>>>
> >>>> Could you please share any ideas on this?
> >>> The bound UDP socket is used for remote calls... Where rpcbind
> >>> is asked to make a remote RPC for another caller...
> >>>
> >>> Antiquated? yes.. but harmless.
> >>
> >> Not quite harmless. It can occupy a privileged port that belongs
> >> to a real service.
> > fair enough...
> >
> >>
> >> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
> >> it doesn't have to hold onto that port indefinitely. It should
> >> be able to bind to an outgoing privileged port whenever it needs
> >> one.
> > Or we just avoid know ports like sm-notify does.
>
> statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead
> of what it does now, IMO.
>
> Note that in both of these cases, that long-lived port is never going
> to be used, going forward:
>
> - no one uses the rpcbind port-forward service that I know of
>
> - NLM is going out of style
>
> If we can make these two cases on-demand instead, so much the better,
> I say. As Mr. Talpey pointed out recently, the only long-lived
> privileged ports we should see on Linux are well-known service
> listeners, not outgoing ports.
This patch should take care of making rpcbind set up the remote call
port on demand. I don't have a whole lot of ways to test it though...
just 'rpcinfo -b' and a handful of one-off programs I wrote a while back
trying to mess with the CALLIT/INDIRECT/BCAST procedures.
I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
I also like the idea of leaving this off by default and adding a
command-line flag to enable it because I'm also not sure if anyone
actually uses it... not to mention there's been at least one CVE in the
past that exploited it (CVE-2015-7236, not sure if there are others).
-Scott
>
> A fix for rpcbind might be to add a cmd-line flag to enable the
> rpcbind forwarding service, and have the service default to disabled.
> I'm not sure why rpcbind would list an outgoing port in it's portmap
> menu. Are you sure that this is the forwarding reflector port?
>
>
> > steved.
> >
> >>
> >>
> >>> steved.
> >>>
> >>>>
> >>>> Brs,
> >>>> Bao
> >>>>
> >>>> On 27 January 2018 at 19:50, Naruto Nguyen <[email protected]> wrote:
> >>>>> I would like to ask you a question regarding the new random UDP port
> >>>>> in rpcbind 0.2.3.
> >>>>>
> >>>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
> >>>>> rpcbind.service, then I do netstat
> >>>>>
> >>>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
> >>>>> 10408/rpcbind
> >>>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
> >>>>> 10408/rpcbind
> >>>>> udp6 0 0 :::111 :::*
> >>>>> 10408/rpcbind
> >>>>> udp6 0 0 :::831 :::*
> >>>>> 10408/rpcbind
> >>>>>
> >>>>> The rpcbind does not only listen on port 111 but also on a random udp
> >>>>> port "831" in this case, this port is changed every time the rpcbind
> >>>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
> >>>>> security. Could you please let me know what this port is for and is
> >>>>> there any way to avoid that like force it listen on a internal
> >>>>> interface rather than on any interfaces like that? I do not see the
> >>>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
> >>>>> from systemd so "-h" option is invalid as the man page says:
> >>>>>
> >>>>>
> >>>>> -h Specify specific IP addresses to bind to for UDP requests.
> >>>>> This option may be specified multiple times and can be used to
> >>>>> restrict the interfaces rpcbind will respond to. Note that when
> >>>>> rpcbind is controlled via sys-
> >>>>> temd's socket activation, the -h option is ignored. In
> >>>>> this case, you need to edit the ListenStream and ListenDgram
> >>>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
> >>>>>
> >>>>> Thanks a lot,
> >>>>> Brs,
> >>>>> Naruto
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>>> the body of a message to [email protected]
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>> the body of a message to [email protected]
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >> --
> >> Chuck Lever
>
> --
> Chuck Lever
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Feb 1, 2018, at 10:29 AM, Scott Mayhew <[email protected]> wrote:
>=20
> On Wed, 31 Jan 2018, Chuck Lever wrote:
>=20
>>=20
>>=20
>>> On Jan 31, 2018, at 2:57 PM, Steve Dickson <[email protected]> =
wrote:
>>>=20
>>>=20
>>>=20
>>> On 01/31/2018 02:43 PM, Chuck Lever wrote:
>>>>=20
>>>>=20
>>>>> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> =
wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
>>>>>> Hello,
>>>>>>=20
>>>>>> Just would like to add for more information, when I start rpcbind
>>>>>> normally, not via systemd, the random UDP is still opened
>>>>>>=20
>>>>>> Could you please share any ideas on this?
>>>>> The bound UDP socket is used for remote calls... Where rpcbind
>>>>> is asked to make a remote RPC for another caller...=20
>>>>>=20
>>>>> Antiquated? yes.. but harmless.
>>>>=20
>>>> Not quite harmless. It can occupy a privileged port that belongs
>>>> to a real service.
>>> fair enough...=20
>>>=20
>>>>=20
>>>> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
>>>> it doesn't have to hold onto that port indefinitely. It should
>>>> be able to bind to an outgoing privileged port whenever it needs
>>>> one.
>>> Or we just avoid know ports like sm-notify does.
>>=20
>> statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead
>> of what it does now, IMO.
>>=20
>> Note that in both of these cases, that long-lived port is never going
>> to be used, going forward:=20
>>=20
>> - no one uses the rpcbind port-forward service that I know of
>>=20
>> - NLM is going out of style
>>=20
>> If we can make these two cases on-demand instead, so much the better,
>> I say. As Mr. Talpey pointed out recently, the only long-lived
>> privileged ports we should see on Linux are well-known service
>> listeners, not outgoing ports.
>=20
> This patch should take care of making rpcbind set up the remote call
> port on demand. I don't have a whole lot of ways to test it though...
> just 'rpcinfo -b' and a handful of one-off programs I wrote a while =
back
> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
>=20
> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
>=20
> I also like the idea of leaving this off by default and adding a
> command-line flag to enable it because I'm also not sure if anyone
> actually uses it... not to mention there's been at least one CVE in =
the
> past that exploited it (CVE-2015-7236, not sure if there are others).
I don't see a problem with taking both approaches
(NET_BIND_SERVICE + bindresvport and a new cmdline option)
> -Scott
>>=20
>> A fix for rpcbind might be to add a cmd-line flag to enable the
>> rpcbind forwarding service, and have the service default to disabled.
>> I'm not sure why rpcbind would list an outgoing port in it's portmap
>> menu. Are you sure that this is the forwarding reflector port?
>>=20
>>=20
>>> steved.
>>>=20
>>>>=20
>>>>=20
>>>>> steved.
>>>>>=20
>>>>>>=20
>>>>>> Brs,
>>>>>> Bao
>>>>>>=20
>>>>>> On 27 January 2018 at 19:50, Naruto Nguyen =
<[email protected]> wrote:
>>>>>>> I would like to ask you a question regarding the new random UDP =
port
>>>>>>> in rpcbind 0.2.3.
>>>>>>>=20
>>>>>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>>>>>>> rpcbind.service, then I do netstat
>>>>>>>=20
>>>>>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>>>>>> 10408/rpcbind
>>>>>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>>>>>>> 10408/rpcbind
>>>>>>> udp6 0 0 :::111 :::*
>>>>>>> 10408/rpcbind
>>>>>>> udp6 0 0 :::831 :::*
>>>>>>> 10408/rpcbind
>>>>>>>=20
>>>>>>> The rpcbind does not only listen on port 111 but also on a =
random udp
>>>>>>> port "831" in this case, this port is changed every time the =
rpcbind
>>>>>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole =
on
>>>>>>> security. Could you please let me know what this port is for and =
is
>>>>>>> there any way to avoid that like force it listen on a internal
>>>>>>> interface rather than on any interfaces like that? I do not see =
the
>>>>>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is =
started
>>>>>>> from systemd so "-h" option is invalid as the man page says:
>>>>>>>=20
>>>>>>>=20
>>>>>>> -h Specify specific IP addresses to bind to for UDP =
requests.
>>>>>>> This option may be specified multiple times and can be used to
>>>>>>> restrict the interfaces rpcbind will respond to. Note that when
>>>>>>> rpcbind is controlled via sys-
>>>>>>> temd's socket activation, the -h option is ignored. In
>>>>>>> this case, you need to edit the ListenStream and ListenDgram
>>>>>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>>>>>>=20
>>>>>>> Thanks a lot,
>>>>>>> Brs,
>>>>>>> Naruto
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe =
linux-nfs" in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at =
http://vger.kernel.org/majordomo-info.html
>>>>>>=20
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe =
linux-nfs" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>=20
>>>> --
>>>> Chuck Lever
>>=20
>> --
>> Chuck Lever
>>=20
>>=20
>>=20
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> <0001-rpcbind-create-the-remote-call-plumbing-on-demand.patch>
--
Chuck Lever
I took sometime to verify this crusty code actually works... It does.
On 01/31/2018 03:09 PM, Chuck Lever wrote:
>
>>>
>>> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
>>> it doesn't have to hold onto that port indefinitely. It should
>>> be able to bind to an outgoing privileged port whenever it needs
>>> one.
You suggesting we do something similar to nsm_clear_capabilities()?
>> Or we just avoid know ports like sm-notify does.
>
> statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead
> of what it does now, IMO.
Well I was talking about the code in sm-notify.c but yes statd
does make the same call to getservbyport().
>
> Note that in both of these cases, that long-lived port is never going
> to be used, going forward:
>
> - no one uses the rpcbind port-forward service that I know of
Has any ever use it?? Why did it even exist??
>
> - NLM is going out of style
Not fast enough! ;-)
>
> If we can make these two cases on-demand instead, so much the better,
> I say. As Mr. Talpey pointed out recently, the only long-lived
> privileged ports we should see on Linux are well-known service
> listeners, not outgoing ports.
I guess this the patch Scott has posted... After a quick
look there appears to be a lot changed which is bit
worrisome...
>
> A fix for rpcbind might be to add a cmd-line flag to enable the
> rpcbind forwarding service, and have the service default to disabled.
I would rather have it auto-magically work ;-)
> I'm not sure why rpcbind would list an outgoing port in it's portmap
> menu. Are you sure that this is the forwarding reflector port?
>
Yes... the listening fd is created by create_rmtcall_fd()
This is not the first time people have complained about
rpbind's rogue listening port :-(
steved.
On 02/01/2018 10:29 AM, Scott Mayhew wrote:
>
> This patch should take care of making rpcbind set up the remote call
> port on demand. I don't have a whole lot of ways to test it though...
> just 'rpcinfo -b' and a handful of one-off programs I wrote a while back
> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
This is where I spent my afternoon yesterday... figuring
out a way to test this code. rpc_call() is my new BFF!
>
> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
I think we need to do what nsm_clear_capabilities() does.
>
> I also like the idea of leaving this off by default and adding a
> command-line flag to enable it because I'm also not sure if anyone
> actually uses it... not to mention there's been at least one CVE in the
> past that exploited it (CVE-2015-7236, not sure if there are others).
I'm not a fan of this idea... I think on demand is a better way
to go... but what do I know?? ;-)
steved.
>
> On Feb 2, 2018, at 10:06 AM, Steve Dickson <[email protected]> wrote:
>
>
>
> On 02/01/2018 10:29 AM, Scott Mayhew wrote:
>>
>> This patch should take care of making rpcbind set up the remote call
>> port on demand. I don't have a whole lot of ways to test it though...
>> just 'rpcinfo -b' and a handful of one-off programs I wrote a while back
>> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
> This is where I spent my afternoon yesterday... figuring
> out a way to test this code. rpc_call() is my new BFF!
Thanks!
>> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
> I think we need to do what nsm_clear_capabilities() does.
Agree, that's exactly what is needed to allow bindresvport
on demand, if rpcbind (or statd) does not run as root.
The only issue I see is that some distros might not have
libcap. There is plenty of infrastructure in nsm/file.c that
deals with the "libcap absent" case, which makes me wonder.
>> I also like the idea of leaving this off by default and adding a
>> command-line flag to enable it because I'm also not sure if anyone
>> actually uses it... not to mention there's been at least one CVE in the
>> past that exploited it (CVE-2015-7236, not sure if there are others).
> I'm not a fan of this idea... I think on demand is a better way
> to go... but what do I know?? ;-)
>
>> I'm not sure why rpcbind would list an outgoing port in it's portmap
>> menu. Are you sure that this is the forwarding reflector port?
>>
> Yes... the listening fd is created by create_rmtcall_fd()
> This is not the first time people have complained about
> rpbind's rogue listening port :-(
Hrm. If this is indeed a listening port, on demand bindresvport
won't help (on demand will only fix outgoing ports). I had
assumed there was a long-lived reserved port that was being
used just for outgoing RPCs, just like statd.
Does that listening port have to be in the privileged port range?
--
Chuck Lever
On 02/02/2018 10:22 AM, Chuck Lever wrote:
>
>
>> On Feb 2, 2018, at 10:06 AM, Steve Dickson <[email protected]> wrote:
>>
>>
>>
>> On 02/01/2018 10:29 AM, Scott Mayhew wrote:
>>>
>>> This patch should take care of making rpcbind set up the remote call
>>> port on demand. I don't have a whole lot of ways to test it though...
>>> just 'rpcinfo -b' and a handful of one-off programs I wrote a while back
>>> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
>> This is where I spent my afternoon yesterday... figuring
>> out a way to test this code. rpc_call() is my new BFF!
>
> Thanks!
>
>
>>> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
>> I think we need to do what nsm_clear_capabilities() does.
>
> Agree, that's exactly what is needed to allow bindresvport
> on demand, if rpcbind (or statd) does not run as root.
With Fedora, rpcbind runs as 'rpc' and statd runs as 'rpcuser'
So changing the capabilities would have to happen early on.
>
> The only issue I see is that some distros might not have
> libcap. There is plenty of infrastructure in nsm/file.c that
> deals with the "libcap absent" case, which makes me wonder.
IDK... Fedora has it...
>
>
>>> I also like the idea of leaving this off by default and adding a
>>> command-line flag to enable it because I'm also not sure if anyone
>>> actually uses it... not to mention there's been at least one CVE in the
>>> past that exploited it (CVE-2015-7236, not sure if there are others).
>> I'm not a fan of this idea... I think on demand is a better way
>> to go... but what do I know?? ;-)
>>
>>> I'm not sure why rpcbind would list an outgoing port in it's portmap
>>> menu. Are you sure that this is the forwarding reflector port?
>>>
>> Yes... the listening fd is created by create_rmtcall_fd()
>> This is not the first time people have complained about
>> rpbind's rogue listening port :-(
>
> Hrm. If this is indeed a listening port, on demand bindresvport
> won't help (on demand will only fix outgoing ports). I had
> assumed there was a long-lived reserved port that was being
> used just for outgoing RPCs, just like statd.
No. create_rmtcall_fd() just calls svc_tli_create() which
does the bindresvport()...
>
> Does that listening port have to be in the privileged port range?
Taking a quick look at mountd and statd I didn't see any code
requiring a privileged port... Maybe to call into the kernel?
steved.
>
>
> --
> Chuck Lever
>
>
>
> On Feb 2, 2018, at 12:00 PM, Scott Mayhew <[email protected]> wrote:
>=20
> On Fri, 02 Feb 2018, Steve Dickson wrote:
>=20
>>=20
>>=20
>> On 02/02/2018 10:22 AM, Chuck Lever wrote:
>>>=20
>>>=20
>>>> On Feb 2, 2018, at 10:06 AM, Steve Dickson <[email protected]> =
wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On 02/01/2018 10:29 AM, Scott Mayhew wrote:
>>>>>=20
>>>>> This patch should take care of making rpcbind set up the remote =
call
>>>>> port on demand. I don't have a whole lot of ways to test it =
though...
>>>>> just 'rpcinfo -b' and a handful of one-off programs I wrote a =
while back
>>>>> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
>>>> This is where I spent my afternoon yesterday... figuring
>>>> out a way to test this code. rpc_call() is my new BFF!
>>>=20
>>> Thanks!
>>>=20
>>>=20
>>>>> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
>>>> I think we need to do what nsm_clear_capabilities() does.
>=20
> Right, I saw that and was going pretty much copy what it does... I =
just
> got busy bug hunting some other stuff.
>=20
>>>=20
>>> Agree, that's exactly what is needed to allow bindresvport
>>> on demand, if rpcbind (or statd) does not run as root.
>> With Fedora, rpcbind runs as 'rpc' and statd runs as 'rpcuser'
>> So changing the capabilities would have to happen early on.
>=20
> statd calls 'prctl(PR_SET_KEEPCAPS,...', calls =
setgroups/setgid/setuid,
> and then nsm_clear_capabilities right after that.
>=20
>>=20
>>>=20
>>> The only issue I see is that some distros might not have
>>> libcap. There is plenty of infrastructure in nsm/file.c that
>>> deals with the "libcap absent" case, which makes me wonder.
>> IDK... Fedora has it...=20
>=20
> So in the case of libcap being absent, I guess it comes down to who's
> actually using the functionality (I've looked a few times in the past
> and never really came up with anything), what program they're trying =
to
> call and what procedure they're trying to call... because if we fail =
to
> get a reserved port then we'll do the bind again with a non-reserved
> port. AFAIK non of the programs care if a NULL request comes from a
> reserved port or not. And check_callit() filters out a lot of the =
other
> procedures (e.g. nothing other than NULL is forwarded to nfsd).
>>>>> I also like the idea of leaving this off by default and adding a
>>>>> command-line flag to enable it because I'm also not sure if anyone
>>>>> actually uses it... not to mention there's been at least one CVE =
in the
>>>>> past that exploited it (CVE-2015-7236, not sure if there are =
others).
>>>> I'm not a fan of this idea... I think on demand is a better way
>>>> to go... but what do I know?? ;-)
>>>>=20
>>>>> I'm not sure why rpcbind would list an outgoing port in it's =
portmap
>>>>> menu. Are you sure that this is the forwarding reflector port?
>>>>>=20
>>>> Yes... the listening fd is created by create_rmtcall_fd()
>>>> This is not the first time people have complained about
>>>> rpbind's rogue listening port :-(=20
>>>=20
>>> Hrm. If this is indeed a listening port, on demand bindresvport
>>> won't help (on demand will only fix outgoing ports). I had
>>> assumed there was a long-lived reserved port that was being
>>> used just for outgoing RPCs, just like statd.
>> No. create_rmtcall_fd() just calls svc_tli_create() which
>> does the bindresvport()...=20
>=20
> Right... I was under the impression that was so these requests could =
be
> handled asynchronously. If rpcbind were to use clnt_call() to forward
> the request then I'd think it would be pretty easy to tie up rpcbind,
> no?
Yes, asynchrony is good. But I don't believe that asynchrony
requires a privileged listener.
IMO it would be better if we could somehow move the CALLIT
listener up into the dynamic port range (above 49151).
In fact that is appropriate for libtirpc to implement for
arbitrary RPC service listeners (including mountd).
svc_tli_create should simply hunt for an available high-numbered
port rather than using bindresvport by default.
_Listeners_ should have no problem using that high port range.
A listener might need to use a well-known port, though, that is
below 1024. In that case, I think svc_tli_create should just use
bind and the library caller needs to have the appropriate
privilege to make it stick.
>>> Does that listening port have to be in the privileged port range?
>> Taking a quick look at mountd and statd I didn't see any code
>> requiring a privileged port... Maybe to call into the kernel?
>=20
> statd needs the privileged port to talk to lockd.
Right, and that's an outgoing port, if my memory serves. The
reason statd holds onto this port is because statd was written a
very long time ago before Linux had libcap (I presume).
If instead it could retain CAP_NET_BIND_SERVICE before it dropped
its root privileges, then it could create that socket on demand,
use bindresvport, and then close it immediately.
--
Chuck Lever
On Fri, 02 Feb 2018, Steve Dickson wrote:
>
>
> On 02/02/2018 10:22 AM, Chuck Lever wrote:
> >
> >
> >> On Feb 2, 2018, at 10:06 AM, Steve Dickson <[email protected]> wrote:
> >>
> >>
> >>
> >> On 02/01/2018 10:29 AM, Scott Mayhew wrote:
> >>>
> >>> This patch should take care of making rpcbind set up the remote call
> >>> port on demand. I don't have a whole lot of ways to test it though...
> >>> just 'rpcinfo -b' and a handful of one-off programs I wrote a while back
> >>> trying to mess with the CALLIT/INDIRECT/BCAST procedures.
> >> This is where I spent my afternoon yesterday... figuring
> >> out a way to test this code. rpc_call() is my new BFF!
> >
> > Thanks!
> >
> >
> >>> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE.
> >> I think we need to do what nsm_clear_capabilities() does.
Right, I saw that and was going pretty much copy what it does... I just
got busy bug hunting some other stuff.
> >
> > Agree, that's exactly what is needed to allow bindresvport
> > on demand, if rpcbind (or statd) does not run as root.
> With Fedora, rpcbind runs as 'rpc' and statd runs as 'rpcuser'
> So changing the capabilities would have to happen early on.
statd calls 'prctl(PR_SET_KEEPCAPS,...', calls setgroups/setgid/setuid,
and then nsm_clear_capabilities right after that.
>
> >
> > The only issue I see is that some distros might not have
> > libcap. There is plenty of infrastructure in nsm/file.c that
> > deals with the "libcap absent" case, which makes me wonder.
> IDK... Fedora has it...
So in the case of libcap being absent, I guess it comes down to who's
actually using the functionality (I've looked a few times in the past
and never really came up with anything), what program they're trying to
call and what procedure they're trying to call... because if we fail to
get a reserved port then we'll do the bind again with a non-reserved
port. AFAIK non of the programs care if a NULL request comes from a
reserved port or not. And check_callit() filters out a lot of the other
procedures (e.g. nothing other than NULL is forwarded to nfsd).
>
> >
> >
> >>> I also like the idea of leaving this off by default and adding a
> >>> command-line flag to enable it because I'm also not sure if anyone
> >>> actually uses it... not to mention there's been at least one CVE in the
> >>> past that exploited it (CVE-2015-7236, not sure if there are others).
> >> I'm not a fan of this idea... I think on demand is a better way
> >> to go... but what do I know?? ;-)
> >>
> >>> I'm not sure why rpcbind would list an outgoing port in it's portmap
> >>> menu. Are you sure that this is the forwarding reflector port?
> >>>
> >> Yes... the listening fd is created by create_rmtcall_fd()
> >> This is not the first time people have complained about
> >> rpbind's rogue listening port :-(
> >
> > Hrm. If this is indeed a listening port, on demand bindresvport
> > won't help (on demand will only fix outgoing ports). I had
> > assumed there was a long-lived reserved port that was being
> > used just for outgoing RPCs, just like statd.
> No. create_rmtcall_fd() just calls svc_tli_create() which
> does the bindresvport()...
Right... I was under the impression that was so these requests could be
handled asynchronously. If rpcbind were to use clnt_call() to forward
the request then I'd think it would be pretty easy to tie up rpcbind,
no?
>
> >
> > Does that listening port have to be in the privileged port range?
> Taking a quick look at mountd and statd I didn't see any code
> requiring a privileged port... Maybe to call into the kernel?
statd needs the privileged port to talk to lockd.
>
> steved.
> >
> >
> > --
> > Chuck Lever
> >
> >
> >
On Wed, Jan 31 2018, Chuck Lever wrote:
>> On Jan 31, 2018, at 2:57 PM, Steve Dickson <[email protected]> wrote:
>>
>>
>>
>> On 01/31/2018 02:43 PM, Chuck Lever wrote:
>>>
>>>
>>>> On Jan 31, 2018, at 2:31 PM, Steve Dickson <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 01/29/2018 01:44 AM, Naruto Nguyen wrote:
>>>>> Hello,
>>>>>
>>>>> Just would like to add for more information, when I start rpcbind
>>>>> normally, not via systemd, the random UDP is still opened
>>>>>
>>>>> Could you please share any ideas on this?
>>>> The bound UDP socket is used for remote calls... Where rpcbind
>>>> is asked to make a remote RPC for another caller...
>>>>
>>>> Antiquated? yes.. but harmless.
>>>
>>> Not quite harmless. It can occupy a privileged port that belongs
>>> to a real service.
>> fair enough...
>>
>>>
>>> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that
>>> it doesn't have to hold onto that port indefinitely. It should
>>> be able to bind to an outgoing privileged port whenever it needs
>>> one.
>> Or we just avoid know ports like sm-notify does.
>
> statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead
> of what it does now, IMO.
>
> Note that in both of these cases, that long-lived port is never going
> to be used, going forward:
>
> - no one uses the rpcbind port-forward service that I know of
ypbind --broadcast
??
I don't see a problem with adding an option to disable it.
I don't think it is harmful enough to make that option the default
(though individual distributors might choose to add the command-line
flag by default).
>
> - NLM is going out of style
"style" isn't a word that I would use with NLM :-)
but I suspect NLM will still be used for some time yet.
>
> If we can make these two cases on-demand instead, so much the better,
> I say. As Mr. Talpey pointed out recently, the only long-lived
> privileged ports we should see on Linux are well-known service
> listeners, not outgoing ports.
>
> A fix for rpcbind might be to add a cmd-line flag to enable the
> rpcbind forwarding service, and have the service default to disabled.
> I'm not sure why rpcbind would list an outgoing port in it's portmap
> menu. Are you sure that this is the forwarding reflector port?
rpcbind doesn't list the outgoing port.
The listing you say was from "netstat -uap" or similar.
NeilBrown
>
>
>> steved.
>>
>>>
>>>
>>>> steved.
>>>>
>>>>>
>>>>> Brs,
>>>>> Bao
>>>>>
>>>>> On 27 January 2018 at 19:50, Naruto Nguyen <[email protected]> wrote:
>>>>>> I would like to ask you a question regarding the new random UDP port
>>>>>> in rpcbind 0.2.3.
>>>>>>
>>>>>> In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
>>>>>> rpcbind.service, then I do netstat
>>>>>>
>>>>>> udp 0 0 0.0.0.0:111 0.0.0.0:*
>>>>>> 10408/rpcbind
>>>>>> udp 0 0 0.0.0.0:831 0.0.0.0:*
>>>>>> 10408/rpcbind
>>>>>> udp6 0 0 :::111 :::*
>>>>>> 10408/rpcbind
>>>>>> udp6 0 0 :::831 :::*
>>>>>> 10408/rpcbind
>>>>>>
>>>>>> The rpcbind does not only listen on port 111 but also on a random udp
>>>>>> port "831" in this case, this port is changed every time the rpcbind
>>>>>> service retstarts. And it listens on 0.0.0.0 so it opens a hole on
>>>>>> security. Could you please let me know what this port is for and is
>>>>>> there any way to avoid that like force it listen on a internal
>>>>>> interface rather than on any interfaces like that? I do not see the
>>>>>> random port on rpcbind 0.2.1, not sure why? As the rpcbind is started
>>>>>> from systemd so "-h" option is invalid as the man page says:
>>>>>>
>>>>>>
>>>>>> -h Specify specific IP addresses to bind to for UDP requests.
>>>>>> This option may be specified multiple times and can be used to
>>>>>> restrict the interfaces rpcbind will respond to. Note that when
>>>>>> rpcbind is controlled via sys-
>>>>>> temd's socket activation, the -h option is ignored. In
>>>>>> this case, you need to edit the ListenStream and ListenDgram
>>>>>> definitions in /usr/lib/systemd/system/rpcbind.socket instead.
>>>>>>
>>>>>> Thanks a lot,
>>>>>> Brs,
>>>>>> Naruto
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> --
>>> Chuck Lever
>
> --
> Chuck Lever
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html