agent fails to start when contents of /var/ossec not owned by ossec

[packetfairy]

Out of the box, the Ubuntu Xenial packaged version of the agent (2.9.3-4466xenial) fails to start on my hosts because the ossec user is denied access to the contents of /var/ossec:

● ossec.service - LSB: Start and stop OSSEC HIDS
   Loaded: loaded (/etc/init.d/ossec; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2018-05-10 01:00:22 UTC; 10min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 10759 ExecStart=/etc/init.d/ossec start (code=exited, status=1/FAILURE)
    Tasks: 1
   Memory: 244.0K
      CPU: 14ms
   CGroup: /system.slice/ossec.service
           └─10777 /var/ossec/bin/ossec-execd

May 10 01:00:01 ip-172-31-2-128 ossec[10759]: 2018/05/10 01:00:01 rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
May 10 01:00:09 ip-172-31-2-128 ossec[10759]: 2018/05/10 01:00:09 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
May 10 01:00:09 ip-172-31-2-128 ossec[10759]: 2018/05/10 01:00:09 rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
May 10 01:00:22 ip-172-31-2-128 ossec[10759]: 2018/05/10 01:00:22 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
May 10 01:00:22 ip-172-31-2-128 ossec[10759]: 2018/05/10 01:00:22 rootcheck(1211): ERROR: Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
May 10 01:00:22 ip-172-31-2-128 ossec[10759]: ossec-syscheckd did not start
May 10 01:00:22 ip-172-31-2-128 systemd[1]: ossec.service: Control process exited, code=exited status=1
May 10 01:00:22 ip-172-31-2-128 systemd[1]: Failed to start LSB: Start and stop OSSEC HIDS.
May 10 01:00:22 ip-172-31-2-128 systemd[1]: ossec.service: Unit entered failed state.
May 10 01:00:22 ip-172-31-2-128 systemd[1]: ossec.service: Failed with result 'exit-code'.

chown -R ossec /var/ossec resolves the issue.

[ddpbsd]

I don't know what's wrong with the ubuntu package, but the fix is incomplete. A lot of the directories and files should be owned by root.

ix# ls -l
total 60
drwx------   2 root   ossec   512 Feb 26 14:54 .ssh
dr-xr-x---   3 root   ossec   512 Feb 26 14:54 active-response
dr-xr-x---   2 root   ossec   512 Apr 30 11:33 agentless
dr-xr-x---   2 root   wheel  1024 Apr 30 11:33 bin
dr-xr-x---   4 root   ossec   512 Apr 30 11:33 etc
drwxr-x---   5 ossec  ossec  2560 May 11 00:01 logs
dr-xr-x---   4 root   wheel   512 Feb 26 14:54 lua
dr-xr-x---  11 root   ossec   512 Feb 26 14:54 queue
dr-xr-x---   4 root   ossec  4608 Apr 30 11:33 rules
drwxr-x---   5 ossec  ossec   512 Feb 26 15:09 stats
dr-xr-x--T   2 root   ossec   512 Feb 26 14:54 tmp
dr-xr-x---   3 root   ossec   512 May  2 09:35 var

In a normal install, most of this is handled by the Makefile.

[packetfairy]

You may be right. The errors logged were red herrings. After much debugging, it looks like the issue is tied specifically to the client.keys file. Because of a rigid umask policy on our systems, that file was created with mode 600 and owned by root:ossec. Ensuring that file has mode 640 with the same ownership appears to resolve the issue.

I suppose it's unfair to blame this on the package. But maybe client.keys should be owned by the user that's going to need it, just in case of things like this. Alternatively, it would have been nice if it logged a "can't read client.keys file" somewhere. It was more than a little frustrating to troubleshoot.

[ddpbsd]

I'll look into logging that better. I can't speak for Daniel Cid, but I believe the reason it's owned by root instead of ossec is because remoted and agentd don't need to modify the file. If those services were exploited, the client.keys should be safe from modification (without a privilege escalation of course).

[ddpbsd]

On failure, it looks like it should have logged error code 1103 from OS_ReadKeys:

#define FOPEN_ERROR   "%s(1103): ERROR: Could not open file '%s' due to [(%d)-(%s)]."