Two program strategy to avoid flex dependency

[Carter Bullard]

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
>
>