How to better parse the path information in file operation

[dreamtale90]

When using audit to monitor file operations (take rename as an example), the file path information reported by aduit is about this：

len[357], node=liuch-PC type=SYSCALL msg=audit(1639712415.637:6250463): arch=c000003e syscall=316 success=yes exit=0 a0=ffffff9c a1=7fff7a853f38 a2=ffffff9c a3=7fff7a853f40 items=4 ppid=30794 pid=4340 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts7 ses=2 comm="mv" exe="/usr/bin/mv" subj==unconfined key="qax_audit"
len[106], node=liuch-PC type=CWD msg=audit(1639712415.637:6250463): cwd="/home/liuch/WorkSpace/pre_research/auditd"
len[251], node=liuch-PC type=PATH msg=audit(1639712415.637:6250463): item=0 name="/home/liuch/WorkSpace/pre_research/auditd" inode=9702300 dev=103:05 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[251], node=liuch-PC type=PATH msg=audit(1639712415.637:6250463): item=1 name="/home/liuch/WorkSpace/pre_research/auditd" inode=9702300 dev=103:05 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[218], node=liuch-PC type=PATH msg=audit(1639712415.637:6250463): item=2 name="234.txt" inode=9702640 dev=103:05 mode=0100644 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[218], node=liuch-PC type=PATH msg=audit(1639712415.637:6250463): item=3 name="345.txt" inode=9702640 dev=103:05 mode=0100644 ouid=1000 ogid=1000 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[111], node=liuch-PC type=PROCTITLE msg=audit(1639712415.637:6250463): proctitle=6D76003233342E747874003334352E747874

However, after loading some drivers, the path information of audit will become more：

len[357], node=liuch-PC type=SYSCALL msg=audit(1639713921.468:6252538): arch=c000003e syscall=316 success=yes exit=0 a0=ffffff9c a1=7ffc9a939f38 a2=ffffff9c a3=7ffc9a939f40 items=6 ppid=30794 pid=8143 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts7 ses=2 comm="mv" exe="/usr/bin/mv" subj==unconfined key="qax_audit"
len[106], node=liuch-PC type=CWD msg=audit(1639713921.468:6252538): cwd="/home/liuch/WorkSpace/pre_research/auditd"
len[218], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=0 name="234.txt" inode=9702640 dev=103:05 mode=0100644 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[251], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=1 name="/home/liuch/WorkSpace/pre_research/auditd" inode=9702300 dev=103:05 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

len[251], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=2 name="/home/liuch/WorkSpace/pre_research/auditd" inode=9702300 dev=103:05 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[251], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=3 name="/home/liuch/WorkSpace/pre_research/auditd" inode=9702300 dev=103:05 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[218], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=4 name="234.txt" inode=9702640 dev=103:05 mode=0100644 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[218], node=liuch-PC type=PATH msg=audit(1639713921.468:6252538): item=5 name="345.txt" inode=9702640 dev=103:05 mode=0100644 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
len[111], node=liuch-PC type=PROCTITLE msg=audit(1639713921.468:6252538): proctitle=6D76003233342E747874003334352E747874
len[59], node=liuch-PC type=EOE msg=audit(1639713921.468:6252538): 

Obviously, if the driver hooks some file related system calls, the path information of audit will be affected. In addition, audit from 2.6 X kernel version is supported. Therefore, how can the path information of the file be parsed more accurately in a variety of complex environments?

[stevegrubb]

The auparse library was created to parse audit events. The path used in a syscall is always the name field in the PATH record. There are 2 strategies. One would be to iterate through the event using auparse_next_record() and auparse_get_type() to see if there is a AUDIT_PATH record. If so, call auparse_find_field() to look for the name field. Then ask for the interpretation using auparse_interpret_realpath(). Another possibility is to use the auparse_normalize API and check if the object is a file or directory. If so, ask for the interpreted object. There should be some examples in the audit code you can look at.

[dreamtale90]

@stevegrubb Thank you very much for your reply. I may not express the problem clearly. Just as you mentioned, I am now using the auparse library to parse the audit event, my problem is how to get an absolute path information of the operational file. Take the rename mentioned earlier, Item0's name is directory of 234.txt, Item1's name is directory of 345.txt, Item2's name is file name of 234.txt, Item3's name is file name of 345.txt. So, the absolute path of 234.txt can be obtained by Item0 and Item2, Item1 and Item3 can get absolute path of 345.txt. But the number of Items in the second log is much more, how can I get the absolute path of the file? Refer to the NameType field? I am not sure if there is still other possible situations. I hope to get better advice.

[stevegrubb]

auparse_interpret_realpath() is intended to give you the full path. But if you want to interpret it yourself, the first parent (0) should go with the delete, the second parent (1) should go with the create nametype. Glue them together and call realpath to handle any relative path names.

[dreamtale90]

@stevegrubb I tested the auparse_interpret_realpath interface, and the result returned when parsing the name is the same as the value. This function of returning realpath does not seem to be very effective. The audit version I am using is audit-userspace-3.0.5.

[stevegrubb]

You'll probably need to build the paths by hand. Renameat is an unusual syscall. I may get around to looking into this more. But not any time soon.

[dreamtale90]

OK, what I found here is that the driver of hook file operation calls user_ path_at function will cause the PATH to increase.

[stevegrubb]

I'm closing out old issues. Not sure if you have worked around this or not. But one other idea is using csv format, the renameat function does have 2 objects and their paths should be accurate. Is there anything else to discuss on this issue?

[stevegrubb]

OK, if we are going to start a new issue for the same problem, I'm closing this one.

[stevegrubb]

Please follow issue #314