Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.

On your random thought,
A few issues from the top of my head:
If it would run chrooted, how would you pass the data to the applications
running outside the jail? You'd have to run a network application plus its
userland network stack per chroot. And if you did that, how would you
coordinate the various processes in such a way they don't use the same
ports? You'd have to use the kernel, probably. And even if you did that, you
probably would have to run your applications as root (or any other special
user, if you use one of those nifty kernel patches) inside the chroot jail
(to access the raw sockets) meaning a remote compromise of such an
application would allow the penetrators to use that particular chroot to
launch other attacks.
Bottom line. KISS. More points of failure come with greater complexity.

About merging the two libraries.
Both have grown to a point where I think it's more important to coordinate
the development of the two libraries such that they get to complement each
other. Though I agree a unified interface would be neat (heh), I'm afraid a
merge would lead to a monolithic (and some people are already throwing up
ideas about adding libdnet and libnids, etc) library which is hard to
maintain, specially some key features.

1) you could completely redesign the two libraries and merge the two
interfaces, thus breaking backwards compatibility and (*maybe*) leading to a
monolithic library

2) you can add an interface layer that unifies the two libraries, but
keeping libnet and libpcap as they are. Though a 3rd interface may
complicate things even further (or not).

3) you could keep the things as they stand but provide an effort to
coordinate the development of both libraries, maybe even share components.

4) you can go for both 2) and 3)

5) you can go for 2) at an initial phase, then slowly go for 1)
--
Henrique Moniz
It's not actually bad rap, I just don't feel it. There, I said it. -- Them

----- Original Message ----- 
From: "Ste Jones" <[email protected]>
To: "Frédéric Raynal" <[email protected]>
Cc: "Mike Schiffman" <[email protected]>; "Guy Harris" <[email protected]>;
"Mark Pizzolato" <[email protected]>;
"Libnet" <[email protected]>; "Michael Richardson"
<[email protected]>; "TCPdump Workers"
<[email protected]>; <[email protected]>
Sent: Thursday, March 25, 2004 7:57 PM
Subject: Re: [tcpdump-workers] libpcap pcap_sendpacket support across
platforms.


> On Thu, 25 Mar 2004 09:45:59 +0100, Frédéric Raynal
> <[email protected]> wrote:
>
> > Hello,
> >
> >
> > On Wed, Mar 24, 2004 at 09:46:15PM -0000, Ste Jones wrote:
> >> > On Mar 23, 2004, at 1:14 PM, Guy Harris wrote:
> >> >> On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote:
> >>
> >> I really think there needs to be sort sort of unification between the
> >> two
> >> libraries libpcap and libnet.... but joining them i don;t know if that
> >> the
> >> best idea.... both require a fair amount of work to maintian so why not
> >> start another api to handle the unification
> >>
> >> The aim of the new api would be to act as the glue between both written
> >> and captured frames, basically a userland stack api (ideally conforming
> >> to
> >> all the relevant RFC's). Frames from libpcap could use this api to
> >> determine what part of the libnet api to use to send frames required to
> >> create a connection for example. The programmer could have full contol
> >> over a stream and not have to worry about each individual frame (unless
> >> they want to)... this would save manually handling connection states,
> >> retransmission problems, fragementation issues and dropped packets
> >> currently faced while using both lipcap and libnet.
> >
> >
> >> Frédéric Raynal implemented something similar for handling
> >> connections a while back but i can;t find it on his site.... looked
> >> pretty good from what i can remember :)
> >
> > Thanks :) But I stopped it because I had another idea to do it in a
> > better way ... but I had no time to do it yet :(
> >
> >> I do think that libpcap should be able to send packets... if someone is
> >> using libpcap to capture connections which should be terminated with a
> >> simple rst, for example,  there should be a way to send a frame as
> >> another
> >> api shouldn;t be required for anything this trivial.... anything more
> >> complicated use libnet :)
> >>
> >> On the flip side disregarding everything i just said..... would one API
> >> for userland networking be that bad idea? many programs require libnet,
> >> libpcap and libdnet why not chuck them all together? would make quite a
> >> bit of sense in the long run would it not? A greater userbase with more
> >> eyes looking at the code can;t be bad.
> >>
> >> A quick list of advantages and disadvanteage for joining the API's
> >>
> >> Advanatages
> >> More people looking at the source code
> >> Easier install one api opposed to two or three api's
> >> Greater portability - libpcap seem to run on everything ;) congratz on
> >> the
> >> recent libnet win32 port btw ;)
> >> Easier API for a developer....interfaces would only need to be selected
> >> once for example.
> >> TCPReplay capabilites within the api?
> >>
> >>
> >> Disadvantages
> >> The api would be more complex and harder to maintain?
> >> Couldn;t really think of any others ;)
> >>
> >>
> >> my initial thoughts as u can probably tell were against the idea....
but
> >> if the main developers are up for it can;t see why not ;)
> >>
> >> enough ranting for this evening ;)
> >
> > Ok, so I start from here, and I'll start with a short story.
> >
> > Some days ago, I sent a mail to Dug Song and Mike about one thing that
> > is in libdnet as I was writting some code to do the same in libnet. 2
> > or 3 days ago, I had a look to the new libpcap, and also found the
> > same feature. That is an API to "handle" the device (getting/setting
> > its adresses, netmask, and things like that). This is definitely
> > something one need when handling "network stuff" and thus should be
> > sahred by all those libraries.
> >
> > Another point for the unification is to avoid the multiplication of
> > the same structures. For instance, both libpcap and libnet use a
> > socket to read or write: why not use the same one? Except for 802.11
> > where listening and writing cant be done at the same time, I cant see
> > any good reason (but I am probably missed it). Idem with the
> > structures describing headers: why should they be define in several
> > places whareas they are always the same?
> >
> > Libpcap does much more than only "listenig on the network". The
> > callback system is pretty cool and that is something similar I wanted
> > to do with the "answering machine" based on network event. But for
> > that, libnids is also very interresting with its good TCP engine
> > (conntrack). Having a userland network stack was part of what I have
> > in mind.
> >
> > There are few projects that are using only libnet, and more that are
> > focusing on libpcap. But most of projects use both of them. And for
> > those ones, a common API with easy ways to "convert" from one to the
> > other would be vey helpful.
> >
> > That was just my 2cts of euros as a user of these 2 wonderful
> > libraries.
> >
> > Fred Raynal
> >
>
> random thought... probably way of the scale but anywayz......... remove
> the network stack from the kernal and implement it userland using a
> combined version of libpcap libnet and libdnet (networkd API
> + deamon?).... bonus being could be run with priverlage seperation,
> chrooted and would not lead to kernal compromise if bugs found...... would
> be similar to what i am trying to do with the gobbler as a userland
> network toolkit for machines without an IP address and also similar to
> Fred's answer machine.
>
> on openbsd you could have bpf reading in frames and dropping the mbuf's
> before any kernal processing is done on the frame (i have implemnted
> something similar so i know its possible).... the frame could then be
> procesed in userland and written back out at frame level from a prog and
> not the kernal
>
> there would also need to be some method so that other programs still think
> they are connecting to a proper socket and not a userland prog...  e.g.
> requiring no change to current programs using a kernal network stack
>
> the obvious problem performance, but how much slower i don;t know?
>
> oh yer there would be the instant firewall feature via dynamic libpcap
> filters... if it doesn;t match the filter drop it
>
> any one up for the challange? ;)
>
> probably goes a tad bit beyond the idea of just joining libnet, libpcap
> and libdnet :P
>
> laters
> Ste Jones
> NetworkPenetration.com
>