Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Christos Zoulas 
On Apr 15,  8:14pm, jnem...@cue.bc.ca (John Nemeth) wrote:
-- Subject: Re: bind reacts badly to dhcpcd losing/regaining connectivity

| } It is a weak copyleft license. It creates problems for us because
| } it will require a lot more work to import, and cause more issues
| } for redistribution.
| 
|  Considering that we have GPL3 stuff in tree that doesn't seem
| to be much of a showstopper.

We are getting rid of GPL code not adding it (we just did bc/dc).
We have grep in process etc.

|  I was more referring to the process of determining the
| destination address of incoming packets and using that address as
| the source address in responses.

IP_PKTINFO?

christos

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Christos Zoulas 
On Apr 16,  6:48am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: bind reacts badly to dhcpcd losing/regaining connectivity

| Date:Sat, 15 Apr 2017 22:16:43 + (UTC)
| From:chris...@astron.com (Christos Zoulas)
| Message-ID:  
| 
|   | > How is this done in NetBSD?
|   | 
|   | bind to INADDR_ANY
| 
| I assume that what jnemeth was really asling, was how to make it work
| the way bind requires, and I suspect the IP_RECVDSTADDR setsockopt()
| along with using recvmsg() is the answer really desired.   (See ip(4))

Ah, yes... Which reminds me that IP_PKTINFO/IP_RECVPKTINFO needs work.

christos

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread John Nemeth 
On Apr 16,  8:23am, Robert Elz wrote:
} 
}   | I suspect the IP_RECVDSTADDR setsockopt()
} 
} Actually, more probably IP_PKTINFO as that's the one named uses for IPv6.
} Either would do for the purpose of determining the incoming address of a
} UDP datagram, so the reply can be sent from the correct src addr, but
} the interface identifier returned by IP_PKTINFO might be needed to make views
} work (that is, even if sent to an external address, a packet received on
} an internal interface is probably shown the internal view, not the external
} one.)

 There are issues with IP_PKTINFO on NetBSD, see 48166 and 48280.

}-- End of excerpt from Robert Elz

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread John Nemeth 
On Apr 15, 10:16pm, Christos Zoulas wrote:
} In article <201704152047.v3fklaxz010...@server.cornerstoneservice.ca>,
} John Nemeth   wrote:
} >
} > What's wrong with the MPL?
} 
} It is a weak copyleft license. It creates problems for us because
} it will require a lot more work to import, and cause more issues
} for redistribution.

 Considering that we have GPL3 stuff in tree that doesn't seem
to be much of a showstopper.

} >} to add an option to do a wild-card bind(2). Given that it is and
} >
} > How is this done in NetBSD?
} 
} bind to INADDR_ANY

 I was more referring to the process of determining the
destination address of incoming packets and using that address as
the source address in responses.

}-- End of excerpt from Christos Zoulas

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Robert Elz 
Date:Sat, 15 Apr 2017 22:16:43 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:  

  | > How is this done in NetBSD?
  | 
  | bind to INADDR_ANY

I assume that what jnemeth was really asling, was how to make it work
the way bind requires, and I suspect the IP_RECVDSTADDR setsockopt()
along with using recvmsg() is the answer really desired.   (See ip(4))

kre

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Christos Zoulas 
In article <201704152047.v3fklaxz010...@server.cornerstoneservice.ca>,
John Nemeth   wrote:
>
> What's wrong with the MPL?

It is a weak copyleft license. It creates problems for us because
it will require a lot more work to import, and cause more issues
for redistribution.

>} to add an option to do a wild-card bind(2). Given that it is and
>
> How is this done in NetBSD?

bind to INADDR_ANY

christos

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread John Nemeth 
On Apr 15,  9:09am, Christos Zoulas wrote:
} On Apr 15,  5:29pm, k...@munnari.oz.au (Robert Elz) wrote:
} 
} | ps: Christos - capabilities (if we had them) would not be the answer - if 
you
} | were to trust bind to be unhackable, then just using root would be just as
} | good a solution, if you (wisely) fail to believe that all named's bugs
} | have been fixed, and that it can still be hacked, then giving it extra
} | capabilities would still be allowing a privilege escalation - not as big
} | a one as directly to root perhaps, but big things can often be built on
} | small steps, and taking over a nameserver's answers (being able to intercept
} | queries to port 53 and return bogus replies) is one of the standard ways
} | to launch all kinds of attacks - allowing a hacker to bind to port 53,
} | and perhaps other priv'd ports, depending upon the granualarity of the 
perms,
} | which a capability based solution would essentially do (given named bugs
} | remain to be exploited) is essentially giving them control of your network.
} 
} I agree. If the bind license was not changed to MPL I would be inclined

 What's wrong with the MPL?

} to add an option to do a wild-card bind(2). Given that it is and

 How is this done in NetBSD?

} we are stuck with a version that we are not going to upgrade until
} that situation changes I'd advise to switch to unbound/nsd. Of course
} it would have been nice if ISC would have dual licensed bind to make
} an exception for the opensource operating systems, but they did not
} do that either.
} 
}-- End of excerpt from Christos Zoulas

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Christos Zoulas 
On Apr 15,  5:29pm, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: bind reacts badly to dhcpcd losing/regaining connectivity

| ps: Christos - capabilities (if we had them) would not be the answer - if you
| were to trust bind to be unhackable, then just using root would be just as
| good a solution, if you (wisely) fail to believe that all named's bugs
| have been fixed, and that it can still be hacked, then giving it extra
| capabilities would still be allowing a privilege escalation - not as big
| a one as directly to root perhaps, but big things can often be built on
| small steps, and taking over a nameserver's answers (being able to intercept
| queries to port 53 and return bogus replies) is one of the standard ways
| to launch all kinds of attacks - allowing a hacker to bind to port 53,
| and perhaps other priv'd ports, depending upon the granualarity of the perms,
| which a capability based solution would essentially do (given named bugs
| remain to be exploited) is essentially giving them control of your network.

I agree. If the bind license was not changed to MPL I would be inclined
to add an option to do a wild-card bind(2). Given that it is and
we are stuck with a version that we are not going to upgrade until
that situation changes I'd advise to switch to unbound/nsd. Of course
it would have been nice if ISC would have dual licensed bind to make
an exception for the opensource operating systems, but they did not
do that either.

christos

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Rhialto 
On Sat 15 Apr 2017 at 13:55:08 +0700, Robert Elz wrote:
> Changing the bind() call is easy, fixing all the places it is assumed to
> work the way it now does is harder.

Ah, that is probably why the following attempt did not cause bind to
open a wildcard socket:

listen-on-v6 { any; };  /* I had this one already */
listen-on { any; }; /* The next two were new */
automatic-interface-scan false;

but this made no difference, bind still logged the same thing as before:

listening on IPv6 interfaces, port 53
listening on IPv4 interface re0, 10.0.0.16#53
listening on IPv4 interface re1, 192.168.178.20#53
listening on IPv4 interface lo0, 127.0.0.1#53

> kre
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly.


signature.asc
Description: PGP signature

Re: bind reacts badly to dhcpcd losing/regaining connectivity

2017-04-15 Thread Robert Elz 
Date:Sat, 15 Apr 2017 03:06:13 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:  

  | Or capabilities, or wildcard bind.

That is what I meant by ...

  | >or to recode the
  | >receive code to use the new way to receive the dest addr of incoming
  | >packets, and to set the source addr of outgoing ones (so just one
  | >UDP socket is needed),

Changing the bind() call is easy, fixing all the places it is assumed to
work the way it now does is harder.

But still the best way (if the facility had existed back in the 80's it
would have been written that way from the start.)

kre