Does this work with recent versions of OSSEC (e.g. 3.5.0) ?

[agriffit79]

Hi,

Just tried this on CentOS 7.7 with ossec-hids-3.5.0 using the atomicorp RPMs and it's got a number of issues. Most of the binaries are not getting labelled correctly so they continue to run unconfined. If I manually label them then I get numerous denies in the audit.log and I have to run in permissive mode to get it to start at all.

What versions did you test against?

Thanks

[georou]

Hi,

The last known working build was CentOS 7.4 + OSSEC 3.3.0.

I'll try to update it over this week/next week but generally an unknown time frame currently.

Cheers

[agriffit79]

So I fixed a couple of the issues. In my build (ossec-hids-agent-3.5.0-9609.el7.art.x86_64.rpm) ossec-logcollector and ossec-syscheckd are symlinks to client-*. So an update to ossec.fe fixed that.

Secondly, it seems that syscheckd and logcollector now need to perform execmem, so another simple fix in ossec.te.

The one I don't understand is /var/ossec/queue/ossec/queue. audit2allow tells me that it is mis-labelled. It should be ossec_analysisd_sock_t but on startup it is created as ossec_queue_t.

Finally, the ossec-agentd process runs unconstrained. I don't know the history of ossec, is this a new daemon? It appears to be completely unreferenced in the existing policy.