Solve bug when processing symbolic links in Whodata

[crolopez]

This PR solves the issue described here #2547.

Since 3.9, Whodata transforms symbolic link paths to real paths before adding them to the Syscheck flow.

The problem comes when configuring the monitoring of a symbolic link since the path comparison algorithms did not take into account that the file could be over a symbolic link.

Since this PR, those directories that are symbolic links will save their real paths too, in order to be able to show the symbolic paths in the alerts if the user configures directory monitoring by indicating the symbolic link.

Alert changes

A new field has been added to the alert that shows the path of the file using the symbolic link, if it comes from one. This path can be found in the JSON alert (symbolic_path) and in the extended format (Symbolic path).

JSON alert example

"syscheck":{
    "path":"/home/user/test/new_file",
    "symbolic_path":"/external/home/user/test/new_file",
    "size_before":"110",
    "size_after":"120",
    "perm_after":"100644",
    "uid_after":"0",
    "gid_after":"0",
    "md5_before":"9f4117385871c99dee3b2b6658ba5009",
    "md5_after":"9336218b86d5caf7cb9a672cecaa18f4",
    "sha1_before":"8be1eea032209993bcb9aa27507814d8dc6d50c0",
    "sha1_after":"93f337a5a94452282fcae1b08bb87fdc856361b3",
    "sha256_before":"2626d17009c82c3406a20aabbe6de980df9327ac47b922cd21250071c81d01a6",
    "sha256_after":"af45600827937ebebdadb43823ff4b6629154e690bc725dd2faf6c44f3977aca",
    "uname_after":"root",
    "gname_after":"root",
    "mtime_before":"2019-04-08T09:41:51",
    "mtime_after":"2019-04-08T10:14:32",
    "inode_after":5324520,
    "event":"modified",
    "audit":{
        "user":{
            "id":"0",
            "name":"root"
        },
        "process":{
            "id":"6250",
            "name":"/usr/bin/bash",
            "ppid":"6230"
        },
        "group":{
            "id":"0",
            "name":"root"
        },
        "login_user":{
            "id":"1000",
            "name":"user"
        },
        "effective_user":{
            "id":"0",
            "name":"root"
        }
    }
}

Extended alert example

** Alert 1554718473.71047: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,
2019 Apr 08 10:14:33 centos7-sources-vmware->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
File '/home/user/test/new_file' checksum changed.
Symbolic path: '/external/home/user/test/new_file'.
Size changed from '110' to '120'
Old md5sum was: '9f4117385871c99dee3b2b6658ba5009'
New md5sum is : '9336218b86d5caf7cb9a672cecaa18f4'
Old sha1sum was: '8be1eea032209993bcb9aa27507814d8dc6d50c0'
New sha1sum is : '93f337a5a94452282fcae1b08bb87fdc856361b3'
Old sha256sum was: '2626d17009c82c3406a20aabbe6de980df9327ac47b922cd21250071c81d01a6'
New sha256sum is : 'af45600827937ebebdadb43823ff4b6629154e690bc725dd2faf6c44f3977aca'
Old modification time was: 'Mon Apr  8 09:41:51 2019', now it is 'Mon Apr  8 10:14:32 2019'
(Audit) User: 'root (0)'
(Audit) Login user: 'user (1000)'
(Audit) Effective user: 'root (0)'
(Audit) Group: 'root (0)'
(Audit) Process id: '6250'
(Audit) Process name: '/usr/bin/bash'

Attributes:
 - Size: 120
 - Date: Mon Apr  8 10:14:32 2019
 - Inode: 5324520
 - User: root (0)
 - Group: root (0)
 - MD5: 9336218b86d5caf7cb9a672cecaa18f4
 - SHA1: 93f337a5a94452282fcae1b08bb87fdc856361b3
 - SHA256: af45600827937ebebdadb43823ff4b6629154e690bc725dd2faf6c44f3977aca
 - Permissions: 100644

Hot update of symbolic links

If the symbolic links indicated in directories change while Syscheck is running, the monitoring of the new directory will be activated, removing the unlinked files from the agent and manager databases silently. This will be done through a checker thread whose scan period can be modified from internal options configuration with syscheck.symlink_scan_interval.

Check the symbolic links with the API

Files derived from symbolic links will include the symbolic_path tag when queried from the API:

curl -u foo:bar -k -X GET "http://127.0.0.1:55000/syscheck/000?pretty"

         {
            "md5": "72c9e5b0e3073ef674ea61b35556c478",
            "perm": "100644",
            "type": "file",
            "uname": "root",
            "symbolic_path": "/home/user/dirlink/file",
            "uid": "0",
            "inode": 101648444,
            "mtime": "2019-04-09 10:37:06",
            "gname": "root",
            "sha1": "67c5fe323214755f0bf88f79cad7b1865c048ba7",
            "file": "/home/user/directory/tests/new_dir/file",
            "date": "2019-04-09 13:09:57",
            "gid": "0",
            "attributes": 0,
            "sha256": "809f2bccf2c78c5c27e9ea4918369c775dd9e41f0593af0d7238e645041d0d9d",
            "size": 7
         }

In this example, /home/user/dirlink points to /home/user/directory/tests/new_dir.

Test

A script like the following can be used to test this feature. If this example is followed, the following configuration should be indicated in ossec.conf:

<directories whodata="yes" check_all="yes">/tmp/dirlink/folder</directories>

#!/bin/bash

n_dirs=10
files_modify=20
sleep_time=0.2
real_dir=/tmp/test
dirlink=/tmp/test/dirlink

for i in $(seq 0 $n_dirs); do mkdir -p $real_dir/dir$i; done

i=0
rm -f $dirlink; ln -s $real_dir/dir$i $dirlink

while true;
do

    for j in $(seq 0 $files_modify); do echo asdf >> "$dirlink/file A $j"; done
    for j in $(seq 0 $files_modify); do echo asdf >> "$dirlink/file B $j"; done
    sleep $sleep_time
    for j in $(seq 0 $files_modify); do echo asdf >> "$dirlink/file A $j"; done
    for j in $(seq 0 $files_modify); do echo asdf >> "$dirlink/file B $j"; done
    sleep $sleep_time
    for j in $(seq 0 $files_modify); do rm -f "$dirlink/file A $j"; done
    for j in $(seq 0 $files_modify); do rm -f "$dirlink/file B $j"; done

    i=$[ ($i + 1) % ($n_dirs - 1) ]

    rm -f $dirlink; ln -s $real_dir/dir$i $dirlink
    echo `date` "'$dirlink' -> '$real_dir/dir$i'"
done