The permission of ar.conf can change when OSSEC Agent started, and may depend on which user started the Agent. You may try starting the agent using '-u ossec -g ossec' arguments to see if it makes a difference.
On Thursday, January 2, 2014 3:48:12 PM UTC-8, Paul L wrote: > > Hi, > > I have a set of largely identical Amazon Linux boxes on the cloud running > the OSSEC client version 2.7. While double-checking the installation, > however, I noticed that the active response file > (/var/ossec/etc/shared/ar.conf) was syncing configuration changes on some > clients but not on others. > > After some examination and Google searching, I noticed that the > permissions on all the files /var/ossec/etc/shared directory differed > between the syncing and non-syncing machines. > > On the non-updating machines the permissions are as follows. I further > noticed that these permissions are identical with those on my OSSEC server. > [root@redacted2]# ls -al /var/ossec/etc/shared > total 172 > drwxrwx--- 2 root ossec 4096 Oct 29 14:21 . > dr-xr-x--- 3 root ossec 4096 Nov 22 13:30 .. > -r--r----- 1 root ossec 157 Oct 29 11:39 ar.conf > -r--r----- 1 root ossec 9501 Oct 29 14:21 cis_debian_linux_rcl.txt > -r--r----- 1 root ossec 8192 Oct 29 14:21 cis_rhel5_linux_rcl.txt > -r--r----- 1 root ossec 14251 Oct 29 14:21 cis_rhel_linux_rcl.txt > -rw-r--r-- 1 ossec ossec 70356 Jan 2 15:37 merged.mg > -r--r----- 1 root ossec 14872 Oct 29 14:21 rootkit_files.txt > -r--r----- 1 root ossec 5193 Oct 29 14:21 rootkit_trojans.txt > -r--r----- 1 root ossec 4457 Oct 29 14:21 system_audit_rcl.txt > -r--r----- 1 root ossec 4682 Oct 29 14:21 win_applications_rcl.txt > -r--r----- 1 root ossec 3859 Oct 29 14:21 win_audit_rcl.txt > -r--r----- 1 root ossec 4929 Oct 29 14:21 win_malware_rcl.txt > > > On the working machines the permissions are as follows: > [root@redacted1]# ls -al /var/ossec/etc/shared/ > total 172 > drwxrwx--- 2 root ossec 4096 Jan 2 14:20 . > dr-xr-x--- 3 root ossec 4096 Oct 30 10:56 .. > -rw-r----- 1 ossec ossec 157 Jan 2 15:30 ar.conf > -rwxrwx--- 1 root ossec 9501 Jan 2 15:30 cis_debian_linux_rcl.txt > -rwxrwx--- 1 root ossec 8192 Jan 2 15:30 cis_rhel5_linux_rcl.txt > -rwxrwx--- 1 root ossec 14251 Jan 2 15:30 cis_rhel_linux_rcl.txt > -rw-r--r-- 1 ossec ossec 70356 Jan 2 15:30 merged.mg > -rwxrwx--- 1 root ossec 14872 Jan 2 15:30 rootkit_files.txt > -rwxrwx--- 1 root ossec 5193 Jan 2 15:30 rootkit_trojans.txt > -rwxrwx--- 1 root ossec 4457 Jan 2 15:30 system_audit_rcl.txt > -rwxrwx--- 1 root ossec 4682 Jan 2 15:30 win_applications_rcl.txt > -rwxrwx--- 1 root ossec 3859 Jan 2 15:30 win_audit_rcl.txt > -rwxrwx--- 1 root ossec 4929 Jan 2 15:30 win_malware_rcl.txt > > > > Manually changing the permissions on the non-updating machines to match > those on the working machines fixed the problem. This is a bit of a hassle, > however. I would like to avoid manual fixes in the future. > > I'm confused as to why the installation process sometimes did not grant > write permissions and gave ownership of ar.conf to user root instead of > user ossec. How does the OSSEC install script set permissions during > installation? Do I perhaps need to change the permissions on the server > ahead of more installations or is there a client install option or > environmental variable that I am missing? > > Best, > Paul > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
