On 29-05-18 17:44, Mark Atwood, Project Manager via devel wrote:
There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.
Cool.
So what iptables (etc) filter ru
> I gather it's been a while since you did anything with raw IP. What you want
> is sendto(2)/sendmsg(2). It's dead easy with those.
Yes. I think most of my work was with connected sockets.
I poked around a bit and haven't figured out how to use it, but it feels like
it should work. Other peo
Hal Murray :
> Can we get the dest address on receive without a separate socket per IP
> Address? recvfrom() gives us the source address. I don't see how to get the
> dest address, but I haven't looked very hard.
Here's the hook:
IP_PKTINFO (since Linux 2.2)
Pass an IP_PKT
Ian Bruene :
> > Are you up for trying? "No" is an acceptable answer - I'm not certain
> > you're ready for this myself.
>
> Yes, though I can't guarantee I won't be screaming for help at 10%
> completion. Also it won't start till after SELF as this does not need to be
> happening right before a
devel@ntpsec.org said:
> Assuming we drop interface-name filtering, everything but the wildcard
> socket is going to go away. I think this will make tracking routing
> unecessary. I hope so, anyway. That code is a mess and I want to nuke it.
We don't track routing in the sense of BGP. We do t
On 05/29/2018 03:54 PM, Eric S. Raymond wrote:
Ian Bruene via devel :
I've skimmed through some of the code associated with these features during
deglobalization. It /needs/ to be cleaned up one way or another. Cleaning it
with a scythe is all the better.
Hmmm. You may have talked yourself i
Yo Eric!
On Tue, 29 May 2018 17:02:47 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Yo Eric!
> >
> > On Tue, 29 May 2018 16:17:36 -0400
> > "Eric S. Raymond" wrote:
> >
> > > Please either choose one drop/no-drop or explain why these cases
> > > should be treated separatel
Gary E. Miller via devel :
> Yo Eric!
>
> On Tue, 29 May 2018 16:17:36 -0400
> "Eric S. Raymond" wrote:
>
> > Please either choose one drop/no-drop or explain why these cases
> > should be treated separately.
>
> If that is the choice, the choice should be no-drop.
Well, then, we're back to sq
Ian Bruene via devel :
> I've skimmed through some of the code associated with these features during
> deglobalization. It /needs/ to be cleaned up one way or another. Cleaning it
> with a scythe is all the better.
Hmmm. You may have talked yourself into a job, apprentice. Because you
are absolu
Yo Eric!
On Tue, 29 May 2018 16:17:36 -0400
"Eric S. Raymond" wrote:
> Please either choose one drop/no-drop or explain why these cases
> should be treated separately.
If that is the choice, the choice should be no-drop.
A ton of ntpd installations were setup a long time ago, and unlikely an
a
Yo Richard!
On Tue, 29 May 2018 15:33:16 -0500
Richard Laager via devel wrote:
> On 05/29/2018 03:32 PM, Jason Azze via devel wrote:
> > I'd be pretty pissed off if, let's say, the Postfix or MySQL people
> > took this attitude. That's why I think I'm misunderstanding.
>
> FWIW, I agree. It'
On 05/29/2018 03:32 PM, Jason Azze via devel wrote:
> I'd be pretty pissed off if, let's say, the Postfix or MySQL people took this
> attitude. That's why I think I'm misunderstanding.
FWIW, I agree. It's perfectly reasonable to list the interfaces to
listen() or bind() to or whatever the call i
On Tue, May 29, 2018, at 4:28 PM, Richard Laager via devel wrote:
> Choosing _which_ interfaces to listen() on at all is not userspace
> packet filtering.
This is my instinct as well. I suspect I don't understand what we're talking
about, so I am hesitant to comment.
Are you suggesting remov
On 05/29/2018 03:17 PM, Eric S. Raymond via devel wrote:
> The point of *this* part of the discussion is that if we accept Mark's
> security rationale (which I don't disagree with) then *every* form of
> userspace packet filtering NTP does is a defect and should be flushed.
Choosing _which_ interf
Hal Murray :
>
> k...@roeckx.be said:
> > Do we only have 1/2 socket by default, or do we still have a listen socket
> > per interface / ip address?
>
> The current code has a socket per interface and a wildcard socket.
>
> It also has another pile of (ugly) code to watch the interfaces and cre
Gary E. Miller via devel :
> > This opens a can of worms, though. Should we drop the entire
> > interface command?
>
> Yes, after years of deprecation. At least to start we want to be drop=in
> replacement for NTP Classic.
I think you're now trying to have things both ways. If we drop filterin
Hal Murray via devel :
>
> > We could kill the interface command, and let the usual syntax error happen.
> > Or we could raise a special syntax error, calling out the need to use the
> > packet filter instead. Then the question becomes, is it a
> > warn-and-continue,
> > or a error-and-halt?
>
k...@roeckx.be said:
> Do we only have 1/2 socket by default, or do we still have a listen socket
> per interface / ip address?
The current code has a socket per interface and a wildcard socket.
It also has another pile of (ugly) code to watch the interfaces and create a
new socket when an in
On Tue, May 29, 2018 at 03:15:15PM -0400, Eric S. Raymond via devel wrote:
> [[interface]]
> +interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ |
> +wildcard+ | 'name' | 'address'[/'prefixlen']]::
> This command controls which network addresses +ntpd+ opens, and
> whether inpu
> We could kill the interface command, and let the usual syntax error happen.
> Or we could raise a special syntax error, calling out the need to use the
> packet filter instead. Then the question becomes, is it a warn-and-continue,
> or a error-and-halt?
Error and halt. (or set a flag to ha
Yo Eric!
On Tue, 29 May 2018 15:15:15 -0400
"Eric S. Raymond via devel" wrote:
> I could summarize it something like this:
>
> "We have removed packet filtering by interface name because we judge
> it's a security-defect attractor. The place to do this is in
> kernel-level packet filters and f
We could kill the interface command, and let the usual syntax error happen.
Or we could raise a special syntax error, calling out the need to use the
packet filter instead. Then the question becomes, is it a
warn-and-continue, or a error-and-halt?
..m
On Tue, May 29, 2018 at 12:17 PM Eric S. Ra
On 05/29/2018 02:15 PM, Eric S. Raymond via devel wrote:
I'm inclined to think dropping this would be a good thing. There's a
lot of code complexity behind that, and that bit abour interface
commands being inoperative if you choose the wrong command-line option
raises my shoot-self-in-foot ala
Hal Murray :
> My reading of Eric's concerns is that he doesn't want to remove a feature
> that somebody is (or might be) using.
That is currect. But we've already removed stuff people might be using
for infosec reasons; I get much less worried if we have that story.
--
http://w
Mark Atwood, Project Manager :
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
>
> The UNIX concept: each tool should do one thing, and do it well.
Nice. Thanks.
mark.atw...@ntpsec.org said:
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
My reading of Eric's concerns is that he doesn't wa
There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.
The UNIX concept: each tool should do one thing, and do it well. The ntpd
should no more do packet filte
27 matches
Mail list logo
