Re: NEW: security/ossec-hids
On Wed, Dec 19, 2018 at 01:19:31AM +, Stuart Henderson wrote: > On 2018/12/12 10:45, Paul Irofti wrote: > > Hi, > > > > Here is an updated port that I would like to import. > > > > This contains many fixes, mostly permissions tweaking but also an rc > > script, and wrappers for the inotify fiasco. It has been tested in > > production since before release and all seems to be running fine. > > > > OK? > > The wrappers fail to install for me (permission denied). But they > shouldn't really be necessary anyway - does the attached version work > for you? It uses -Wl,-rpath to hopefully fix up library paths instead, > and I passed CFLAGS across (you successfully removed upstreams > hardcoded values but didn't use ports ones, so it was building > without any -O flags). > > The UIDs need an update to free spots in infrastructure/db/user.list. > I haven't done that in the attached file to ease your testing, but > that will need doing before commit. > > (There are some other tweaks to make - hardcoded /usr/local in a couple > of places, and I think some chunks of patch are probably not needed - > but I don't think those are blockers and can be done after it's in tree). Hi Stuart, Thank you very much for the fixes. I have updated the tarbal you sent to include the necessary PLIST changes: removing the wrappers and updating the user and group IDs. Here is also a patch for the user.list Is it ok to import the port now? I will take care of the rest of the fixes suggested by you and Dan afterwards. Thanks, Paul Index: infrastructure/db/user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.334 diff -u -p -u -p -r1.334 user.list --- infrastructure/db/user.list 18 Dec 2018 19:28:52 - 1.334 +++ infrastructure/db/user.list 20 Dec 2018 12:59:44 - @@ -335,3 +335,6 @@ id usergroup port options 824 _traccar _traccargeo/traccar 825 _go-ipfs _go-ipfsnet/go-ipfs 826 _telegraf _telegraf sysutils/telegraf +827 _ossec _ossec security/ossec-hids +828 _ossecm_ossec security/ossec-hids +829 _ossecr_ossec security/ossec-hids ossec-hids.tgz Description: application/tar-gz
Re: NEW: security/ossec-hids
On Tue, Dec 18, 2018 at 8:21 PM Stuart Henderson wrote: > > On 2018/12/12 10:45, Paul Irofti wrote: > > Hi, > > > > Here is an updated port that I would like to import. > > > > This contains many fixes, mostly permissions tweaking but also an rc > > script, and wrappers for the inotify fiasco. It has been tested in > > production since before release and all seems to be running fine. > > > > OK? > > The wrappers fail to install for me (permission denied). But they > shouldn't really be necessary anyway - does the attached version work > for you? It uses -Wl,-rpath to hopefully fix up library paths instead, > and I passed CFLAGS across (you successfully removed upstreams > hardcoded values but didn't use ports ones, so it was building > without any -O flags). > > The UIDs need an update to free spots in infrastructure/db/user.list. > I haven't done that in the attached file to ease your testing, but > that will need doing before commit. > > (There are some other tweaks to make - hardcoded /usr/local in a couple > of places, and I think some chunks of patch are probably not needed - > but I don't think those are blockers and can be done after it's in tree). > Hi! I fumble with the OSSEC source (although I won't take responsibility for creating the build system), and thought I'd chime in with a couple of things. I am fairly sleep deprived today, so feel free to ignore if I'm way off base. The zlib patch can be removed by using the 'ZLIB_SYSTEM=yes' option. I haven't noticed any issues when using the one provided by OpenBSD. I'm hoping to move in this direction by default Using 'LUA_ENABLE=no' could remove the need for the the lua patch. It isn't really used at the moment, and I'd much prefer to use a system provided lua if/when we get to it. Thanks for the comments on the build system. It's really something we need to work on, just need to find the time =] dan
Re: NEW: security/ossec-hids
On 2018/12/19 01:19, Stuart Henderson wrote: > On 2018/12/12 10:45, Paul Irofti wrote: > > Hi, > > > > Here is an updated port that I would like to import. > > > > This contains many fixes, mostly permissions tweaking but also an rc > > script, and wrappers for the inotify fiasco. It has been tested in > > production since before release and all seems to be running fine. > > > > OK? > > The wrappers fail to install for me (permission denied). But they > shouldn't really be necessary anyway - does the attached version work > for you? It uses -Wl,-rpath to hopefully fix up library paths instead, > and I passed CFLAGS across (you successfully removed upstreams > hardcoded values but didn't use ports ones, so it was building > without any -O flags). > > The UIDs need an update to free spots in infrastructure/db/user.list. > I haven't done that in the attached file to ease your testing, but > that will need doing before commit. > > (There are some other tweaks to make - hardcoded /usr/local in a couple > of places, and I think some chunks of patch are probably not needed - > but I don't think those are blockers and can be done after it's in tree). > [the sender would like to recall this message and add an attachment] :-) ossec-hids,2.tgz Description: Binary data
Re: NEW: security/ossec-hids
On 2018/12/12 10:45, Paul Irofti wrote: > Hi, > > Here is an updated port that I would like to import. > > This contains many fixes, mostly permissions tweaking but also an rc > script, and wrappers for the inotify fiasco. It has been tested in > production since before release and all seems to be running fine. > > OK? The wrappers fail to install for me (permission denied). But they shouldn't really be necessary anyway - does the attached version work for you? It uses -Wl,-rpath to hopefully fix up library paths instead, and I passed CFLAGS across (you successfully removed upstreams hardcoded values but didn't use ports ones, so it was building without any -O flags). The UIDs need an update to free spots in infrastructure/db/user.list. I haven't done that in the attached file to ease your testing, but that will need doing before commit. (There are some other tweaks to make - hardcoded /usr/local in a couple of places, and I think some chunks of patch are probably not needed - but I don't think those are blockers and can be done after it's in tree).
Re: NEW: security/ossec-hids
Hi, Here is an updated port that I would like to import. This contains many fixes, mostly permissions tweaking but also an rc script, and wrappers for the inotify fiasco. It has been tested in production since before release and all seems to be running fine. OK? Paul On Fri, Sep 21, 2018 at 12:01:55PM +0300, Paul Irofti wrote: > Hi, > > Attached is a new port for ossec-hids. > > OSSEC is a scalable, multi-platform, open source Host-based Intrusion > Detection > System (HIDS). It has a powerful correlation and analysis engine, integrating > log analysis, file integrity checking, Windows registry monitoring, > centralized > policy enforcement, rootkit detection, real-time alerting and active response. > > > Testing has shown encouraging results. The only issue that I am aware of > at this moment is that real-time file monitoring sometime stops working > without anything in the logs or any daemons crashing. I plan on testing > this further, but it might be a software defect not a porting omission > on my end. > > > Any comments? OK to import? > > Thanks, > Paul ossec-hids.tgz Description: application/tar-gz
Re: NEW: security/ossec-hids
On Thu, Oct 04, 2018 at 12:39:57PM +0100, Stuart Henderson wrote:
> On 2018/10/04 12:47, Paul Irofti wrote:
> > > Sorry I don't think it's ready for commit yet, there are a few problems ..
> >
> > Sure, thank you for reviewing this!
> >
> > > - Bad distfile name, it's already using an on-the-fly
> > > tarball from github anyway so the easy fix is to use the GH_* scaffolding
> > >
> > > - Compiler command lines are hidden which makes it hard to track down some
> > > problems in bulk build logs
> > >
> > > - Needs WANTLIB etc.
> > >
> > > (Diff for the above three attached)
> >
> > Thanks!
> >
> > > - In the build of the embedded copy of libz, it's forcing "gcc -O3"
> > > and for lua it does use ${CC} but forces -O2, looks like forced -O2 in
> > > ossec's own files too?
> >
> > I try not to touch hardcoded optimization levels. Which I know is a
> > faux-pas in our ports tree, but I tend to trust the software developers
> > more now that we have modern compilers in the tree.
> >
> > If needed, I will fix this.
>
> Some arches have modern compilers, but we had something that needed -O1
> to avoid a compiler problem just last week (and modern compilers keep
> adding more and more optimisations, and I'm not sure I trust people that
> came up with the build system to track this and know which levels are
> really safe on the various compilers that might be used..)
>
> > > - Patches have hardcoded /usr/local
> >
> > Yes. I thought that we decided against supporting other install
> > directories. I can substitute them for TRUEPREFIX if needed.
>
> espie has been fixing a bunch of things that don't do this recently,
> so I don't think that has been decided :)
>
> For "things relating to the current port" (connected with the install
> location etc) it's TRUEPREFIX, for "things from another port" it's
> LOCALBASE so that's what you need for CFLAGS/LDFLAGS lines etc.
>
> (I'm not convinced the distinction between TRUEPREFIX/LOCALBASE in ports
> makes sense, but that's how it's handled at the moment, so best to follow
> that and save Antoine from fixing it later ;)
Here is a new tarbal with the fixes from you included. OK?
ossec-hids.tgz
Description: application/tar-gz
Re: NEW: security/ossec-hids
On Thu, Oct 04, 2018 at 12:39:57PM +0100, Stuart Henderson wrote:
> On 2018/10/04 12:47, Paul Irofti wrote:
> > > Sorry I don't think it's ready for commit yet, there are a few problems ..
> >
> > Sure, thank you for reviewing this!
> >
> > > - Bad distfile name, it's already using an on-the-fly
> > > tarball from github anyway so the easy fix is to use the GH_* scaffolding
> > >
> > > - Compiler command lines are hidden which makes it hard to track down some
> > > problems in bulk build logs
> > >
> > > - Needs WANTLIB etc.
> > >
> > > (Diff for the above three attached)
> >
> > Thanks!
> >
> > > - In the build of the embedded copy of libz, it's forcing "gcc -O3"
> > > and for lua it does use ${CC} but forces -O2, looks like forced -O2 in
> > > ossec's own files too?
> >
> > I try not to touch hardcoded optimization levels. Which I know is a
> > faux-pas in our ports tree, but I tend to trust the software developers
> > more now that we have modern compilers in the tree.
> >
> > If needed, I will fix this.
>
> Some arches have modern compilers, but we had something that needed -O1
> to avoid a compiler problem just last week (and modern compilers keep
> adding more and more optimisations, and I'm not sure I trust people that
> came up with the build system to track this and know which levels are
> really safe on the various compilers that might be used..)
OK. I'll fix it. Don't want to argue :)
> > > - Patches have hardcoded /usr/local
> >
> > Yes. I thought that we decided against supporting other install
> > directories. I can substitute them for TRUEPREFIX if needed.
>
> espie has been fixing a bunch of things that don't do this recently,
> so I don't think that has been decided :)
>
> For "things relating to the current port" (connected with the install
> location etc) it's TRUEPREFIX, for "things from another port" it's
> LOCALBASE so that's what you need for CFLAGS/LDFLAGS lines etc.
>
> (I'm not convinced the distinction between TRUEPREFIX/LOCALBASE in ports
> makes sense, but that's how it's handled at the moment, so best to follow
> that and save Antoine from fixing it later ;)
I'll fix this too then...
> > > - (also it's not ideal that it's NO_BUILD and everything is built in
> > > "make install", though upstream doesn't make this easy to fix..)
> >
> > It's a horror the way they build it. I would basically have to rewrite
> > the entire build system for them and then maintain it on each release.
> > It has already been a disgusting experience tracking down the file
> > permissions inside pkg/PLIST :(
>
> It is full of wonders. Considering what ossec-hids is used for, I find it
> quite surprising they have written a build system that's A) clearly intended
> for compiling directly on the monitored machine itself and B) with the whole
> build intending to run as root. I guess this is the way of companies who
> make Enterprise Cybersecurity Solutions.
I agree :)
Re: NEW: security/ossec-hids
On 2018/10/04 12:47, Paul Irofti wrote:
> > Sorry I don't think it's ready for commit yet, there are a few problems ..
>
> Sure, thank you for reviewing this!
>
> > - Bad distfile name, it's already using an on-the-fly
> > tarball from github anyway so the easy fix is to use the GH_* scaffolding
> >
> > - Compiler command lines are hidden which makes it hard to track down some
> > problems in bulk build logs
> >
> > - Needs WANTLIB etc.
> >
> > (Diff for the above three attached)
>
> Thanks!
>
> > - In the build of the embedded copy of libz, it's forcing "gcc -O3"
> > and for lua it does use ${CC} but forces -O2, looks like forced -O2 in
> > ossec's own files too?
>
> I try not to touch hardcoded optimization levels. Which I know is a
> faux-pas in our ports tree, but I tend to trust the software developers
> more now that we have modern compilers in the tree.
>
> If needed, I will fix this.
Some arches have modern compilers, but we had something that needed -O1
to avoid a compiler problem just last week (and modern compilers keep
adding more and more optimisations, and I'm not sure I trust people that
came up with the build system to track this and know which levels are
really safe on the various compilers that might be used..)
> > - Patches have hardcoded /usr/local
>
> Yes. I thought that we decided against supporting other install
> directories. I can substitute them for TRUEPREFIX if needed.
espie has been fixing a bunch of things that don't do this recently,
so I don't think that has been decided :)
For "things relating to the current port" (connected with the install
location etc) it's TRUEPREFIX, for "things from another port" it's
LOCALBASE so that's what you need for CFLAGS/LDFLAGS lines etc.
(I'm not convinced the distinction between TRUEPREFIX/LOCALBASE in ports
makes sense, but that's how it's handled at the moment, so best to follow
that and save Antoine from fixing it later ;)
> > - (also it's not ideal that it's NO_BUILD and everything is built in
> > "make install", though upstream doesn't make this easy to fix..)
>
> It's a horror the way they build it. I would basically have to rewrite
> the entire build system for them and then maintain it on each release.
> It has already been a disgusting experience tracking down the file
> permissions inside pkg/PLIST :(
It is full of wonders. Considering what ossec-hids is used for, I find it
quite surprising they have written a build system that's A) clearly intended
for compiling directly on the monitored machine itself and B) with the whole
build intending to run as root. I guess this is the way of companies who
make Enterprise Cybersecurity Solutions.
Re: NEW: security/ossec-hids
> Sorry I don't think it's ready for commit yet, there are a few problems ..
Sure, thank you for reviewing this!
> - Bad distfile name, it's already using an on-the-fly
> tarball from github anyway so the easy fix is to use the GH_* scaffolding
>
> - Compiler command lines are hidden which makes it hard to track down some
> problems in bulk build logs
>
> - Needs WANTLIB etc.
>
> (Diff for the above three attached)
Thanks!
> - In the build of the embedded copy of libz, it's forcing "gcc -O3"
> and for lua it does use ${CC} but forces -O2, looks like forced -O2 in
> ossec's own files too?
I try not to touch hardcoded optimization levels. Which I know is a
faux-pas in our ports tree, but I tend to trust the software developers
more now that we have modern compilers in the tree.
If needed, I will fix this.
> - Patches have hardcoded /usr/local
Yes. I thought that we decided against supporting other install
directories. I can substitute them for TRUEPREFIX if needed.
> - (also it's not ideal that it's NO_BUILD and everything is built in
> "make install", though upstream doesn't make this easy to fix..)
It's a horror the way they build it. I would basically have to rewrite
the entire build system for them and then maintain it on each release.
It has already been a disgusting experience tracking down the file
permissions inside pkg/PLIST :(
Re: NEW: security/ossec-hids
On 2018/10/03 15:08, Paul Irofti wrote:
> On Fri, Sep 21, 2018 at 12:01:55PM +0300, Paul Irofti wrote:
> > Hi,
> >
> > Attached is a new port for ossec-hids.
> >
> > OSSEC is a scalable, multi-platform, open source Host-based Intrusion
> > Detection
> > System (HIDS). It has a powerful correlation and analysis engine,
> > integrating
> > log analysis, file integrity checking, Windows registry monitoring,
> > centralized
> > policy enforcement, rootkit detection, real-time alerting and active
> > response.
> >
> >
> > Testing has shown encouraging results. The only issue that I am aware of
> > at this moment is that real-time file monitoring sometime stops working
> > without anything in the logs or any daemons crashing. I plan on testing
> > this further, but it might be a software defect not a porting omission
> > on my end.
> >
> >
> > Any comments? OK to import?
> >
> > Thanks,
> > Paul
>
> Here is an updated tarbal with a few fixes. I plan on importing this
> later today or tomorrow morning if noboday objects.
Sorry I don't think it's ready for commit yet, there are a few problems ..
- Bad distfile name, it's already using an on-the-fly
tarball from github anyway so the easy fix is to use the GH_* scaffolding
- Compiler command lines are hidden which makes it hard to track down some
problems in bulk build logs
- Needs WANTLIB etc.
(Diff for the above three attached)
- In the build of the embedded copy of libz, it's forcing "gcc -O3"
and for lua it does use ${CC} but forces -O2, looks like forced -O2 in
ossec's own files too?
- Patches have hardcoded /usr/local
- (also it's not ideal that it's NO_BUILD and everything is built in
"make install", though upstream doesn't make this easy to fix..)
diff --git a/Makefile b/Makefile
index 6a0d1f1..03ec83c 100644
--- a/Makefile
+++ b/Makefile
@@ -2,23 +2,22 @@
COMMENT = host-based intrusion detection system
-V =3.0.0
-DISTNAME = ${V}
+GH_ACCOUNT = ossec
+GH_PROJECT = ossec-hids
+GH_TAGNAME = 3.0.0
+
CATEGORIES = security
-PKGNAME = ossec-hids-${V}
-WRKDIST = ${WRKDIR}/${PKGNAME}
-HOMEPAGE = http://www.ossec.net/
-MASTER_SITES = https://github.com/ossec/ossec-hids/archive/
+HOMEPAGE = https://www.ossec.net/
MAINTAINER = Paul Irofti
# GPLv2
PERMIT_PACKAGE_CDROM = Yes
-BUILD_DEPENDS =devel/libinotify \
- devel/libmagic
-RUN_DEPENDS = devel/libinotify \
+WANTLIB += c crypto lib/inotify/inotify m magic pthread ssl
+
+LIB_DEPENDS = devel/libinotify \
devel/libmagic
USE_GMAKE =Yes
@@ -39,7 +38,8 @@ INSTALL_FLAGS = USER_NO_STOP=y \
USER_ENABLE_FIREWALL_RESPONSE=y \
USER_ENABLE_SYSLOG=y \
USER_AGENT_SERVER_IP="127.0.0.1" \
- USE_INOTIFY=y
+ USE_INOTIFY=y \
+ V=1
do-install:
cd ${WRKBUILD} && ${INSTALL_FLAGS} /bin/sh install.sh
Re: NEW: security/ossec-hids
On Fri, Sep 21, 2018 at 12:01:55PM +0300, Paul Irofti wrote: > Hi, > > Attached is a new port for ossec-hids. > > OSSEC is a scalable, multi-platform, open source Host-based Intrusion > Detection > System (HIDS). It has a powerful correlation and analysis engine, integrating > log analysis, file integrity checking, Windows registry monitoring, > centralized > policy enforcement, rootkit detection, real-time alerting and active response. > > > Testing has shown encouraging results. The only issue that I am aware of > at this moment is that real-time file monitoring sometime stops working > without anything in the logs or any daemons crashing. I plan on testing > this further, but it might be a software defect not a porting omission > on my end. > > > Any comments? OK to import? > > Thanks, > Paul Here is an updated tarbal with a few fixes. I plan on importing this later today or tomorrow morning if noboday objects. Paul ossec-hids.tgz Description: application/tar-gz
NEW: security/ossec-hids
Hi, Attached is a new port for ossec-hids. OSSEC is a scalable, multi-platform, open source Host-based Intrusion Detection System (HIDS). It has a powerful correlation and analysis engine, integrating log analysis, file integrity checking, Windows registry monitoring, centralized policy enforcement, rootkit detection, real-time alerting and active response. Testing has shown encouraging results. The only issue that I am aware of at this moment is that real-time file monitoring sometime stops working without anything in the logs or any daemons crashing. I plan on testing this further, but it might be a software defect not a porting omission on my end. Any comments? OK to import? Thanks, Paul ossec-hids.tgz Description: application/tar-gz
