Two program strategy to avoid flex dependency

[Chas DiFatta]

That's ok by me, as long as it does not hinder adoption by
requiring users to install yet another periphery library.
Yes not a problem for Linux system users.

Does this hinder the porting to the WIN2000 platform?

	...cd

> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Carter Bullard
> Sent: Monday, September 11, 2000 5:23 AM
> To: 'Neil Long'; 'Argus (E-mail)'
> Subject: RE: Two program strategy to avoid flex dependency
>
>
> Well,
>    That will make it much easier and solve a
> few fundamental problems on the way.  Does anyone
> have any problems with a flex/bison dependency?
>
> Carter
>
> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Neil Long
> Sent: Monday, September 11, 2000 8:18 AM
> To: carter at qosient.com; Argus (E-mail)
> Subject: Re: Two program strategy to avoid flex dependency
>
>
> Why not just make flex a package required add-on?
>
> If it provides the added functionality (that is there in *BSD and
> Linux, etc
> ? others??) you/we need then there are plenty of flex pre-packaged options
> out there.
>
> After all the configure script uses gcc by default (and ignores the Sun C
> compiler even if it is there).
>
> Not ideal I am sure but it would be fine by me. Anyone able to
> test other OS
> dependencies?
>
> Neil
>
> > Hey Neil,
> >    My copy of lex is actually flex, and the Solaris
> > 2.7 lex is severely hampered, so you are right.
> >
> >    So it appears that we have an existing dependency on
> > flex/bison, which may not be what we want.  The problem.
> >
> > There is no way that we can support remote filtering,
> > without having two compilers, one for the tcpdump style
> > packet filter, and one for the argus record filter.
> > Flex/bison support the ability to rename the "yy" namespace
> > that is used by yacc style compilers, so that you can
> > avoid collisions, but traditional lex/yacc combinations
> > don't support this.  So, major problem.
> >
> >    A solution is to structure Argus into two independent
> > programs.  One is the Argus flow engine, which will use
> > the tcpdump compiler, (we pick it up with libpcap.a),
> > and the other is the Argus record output multiplexor,
> > which gets a single stream from the flow engine and then
> > filters and sends records to their appropriate places,
> > such as files, sockets, pipes, etc.....
> >
> >   This strategy is easy to implement, but it introduces
> > problems, primarily security problems.   Very easy to
> > modify the output program to filter out specific records,
> > and so the entire system has an Achilles heel, if you will.
> >
> >    Suggestions?
> >
> > Carter
> >
> > -----Original Message-----
> > From: Carter Bullard [mailto:carter at qosient.com]
> > Sent: Monday, September 11, 2000 7:37 AM
> > To: 'Neil Long'; Argus (E-mail)
> > Subject: Older lexi issue
> >
> >
> > Hey Neil,
> >    Lex takes the -P option on my Linux machine, no problem.
> > This is lex 2.5.4.  Because we are now merging the two
> > compilers together, we have to have this option in order
> > for the strategy to work.  Is there not a switch on your
> > lex that does the same thing as the -P option (specify
> > scanner prefix other than 'yy')?
> >
> >    If not, we'll have to have two programs.  The argus
> > engine and the output mutliplexer will have to be
> > independent programs.  This causes potential security
> > gotchas, because we'll have to fork/exec something in
> > the filesystem, which is a wonderful opportunity for
> > someone to swap programs.  That would give someone the
> > opportunity to put in their own embedded filters, thus
> > hiding tracks, or generating false trails.
> >
> >    We can do it, but I'd rather not.
> >
> > Carter
> >
> >
> >
> > -----Original Message-----
> > From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
> > Sent: Monday, September 11, 2000 4:43 AM
> > To: carter at qosient.com
> > Subject: Re: argus-2.0.0c available
> >
> >
> > Hi
> >
> > There is a problem with the 'fix' for configure to enable
> -Pargus in that
> > lex does not support the -P option, it is flex specific.
> >
> > This kinda looks like flex is a pre-requisite??
> >
> > Neil
> >
> >
>
>