Hi all,
Having some issues packaging up snort (and its many different builds).
Snort with in-line functionality does not build at all. I get the errors that are reported (but un-actioned and reported on FC3) in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html
The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package.
However, whilst this may work for a one of build, its not elegant for a mass deployment of snort installs via rpm.
Has anyone got some suggestions on what should be done about this or how to work around it (from a packaging standpoint) ?
Thanks in advance.
Michael
On Mon, 2006-02-13 at 15:03 +1300, Michael J Knox wrote:
Hi all,
Having some issues packaging up snort (and its many different builds).
Snort with in-line functionality does not build at all. I get the errors that are reported (but un-actioned and reported on FC3) in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html
The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package.
it's a problem in that apparently snort wants to use kernel internal headers.... which is wrong on so many levels it's not funny. That or snort "forgets" to include dependent headers... if you include kernel headers (even derived cleaned up ones like in glibc-kernheaders) you need to know what you're doing...
On Mon, 2006-02-13 at 08:37 +0100, Arjan van de Ven wrote:
On Mon, 2006-02-13 at 15:03 +1300, Michael J Knox wrote:
Hi all,
Having some issues packaging up snort (and its many different builds).
Snort with in-line functionality does not build at all. I get the errors that are reported (but un-actioned and reported on FC3) in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html
The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package.
it's a problem in that apparently snort wants to use kernel internal headers.... which is wrong on so many levels it's not funny. That or snort "forgets" to include dependent headers... if you include kernel headers (even derived cleaned up ones like in glibc-kernheaders) you need to know what you're doing...
So what would be the best way to "fix" this?
Michael
On Mon, 2006-02-13 at 08:45 +0100, Arjan van de Ven wrote:
So what would be the best way to "fix" this?
the latest snort just compiles for me... so maybe use that?
Ummm.. Are you enabling inline (--enable-inline)? The 2.4.3 release (current stable) and CVS head still fail with the below:
In file included from /usr/include/linux/netfilter_ipv4/ip_queue.h:10, from /usr/include/libipq.h:37, from ../../src/inline.h:8, from ../../src/snort.h:36, from spo_alert_fast.c:51: /usr/include/linux/if.h:59: error: redefinition of ‘struct ifmap’ /usr/include/linux/if.h:77: error: redefinition of ‘struct ifreq’ /usr/include/linux/if.h:126: error: redefinition of ‘struct ifconf’ spo_alert_fast.c: In function ‘AlertFastInit’: spo_alert_fast.c:124: warning: pointer targets in passing argument 1 of ‘ParseAlertFastArgs’ differ in signedness make[3]: *** [spo_alert_fast.o] Error 1
This is FC4 will all updates as of 20mins ago.
Michael
On Mon, Feb 13, 2006 at 03:03:48PM +1300, Michael J Knox wrote:
The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package.
Kernel includes should never be used from userspace.
Has anyone got some suggestions on what should be done about this or how to work around it (from a packaging standpoint) ?
If the glibc-kernheaders are insufficient, and snort is sticking to documented public interfaces, then glibc-kernheaders should be fixed to define those interfaces.
On Mon, 2006-02-13 at 09:35 -0500, Chuck Anderson wrote:
On Mon, Feb 13, 2006 at 03:03:48PM +1300, Michael J Knox wrote:
The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package.
Kernel includes should never be used from userspace.
Has anyone got some suggestions on what should be done about this or how to work around it (from a packaging standpoint) ?
If the glibc-kernheaders are insufficient, and snort is sticking to documented public interfaces, then glibc-kernheaders should be fixed to define those interfaces.
Ok, so do I go back to snort and find out whats what or does RH update glibc-kernheaders?
Michael
Ok, so do I go back to snort and find out whats what or does RH update glibc-kernheaders?
Isn't inline snort a kernel patch? If so it has to be applied to the kernel or something like that.
The code for snort is very buggy. I did a code review a while back and was not happy with what I saw. The code I saw could get you hacked due to poor programming practices. I reported this on their mail list to no avail. I'd be very careful how I add snort to a network.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 2006-02-14 at 05:52 -0800, Steve G wrote:
Ok, so do I go back to snort and find out whats what or does RH update glibc-kernheaders?
Isn't inline snort a kernel patch? If so it has to be applied to the kernel or something like that.
The code for snort is very buggy. I did a code review a while back and was not happy with what I saw. The code I saw could get you hacked due to poor programming practices. I reported this on their mail list to no avail. I'd be very careful how I add snort to a network.
No inline is not a kernel patch.
Michael
-
Arjan van de Ven -
Chuck Anderson -
Michael J. Knox -
Steve G