<div dir="ltr"><div>Hello Steve,</div><div><br></div><div>Thank you, that's very helpful.  <br></div><div><span style="color:rgb(142,124,195)"><br></span></div><div><span style="color:rgb(142,124,195)">>
The 
compound events always have a syscall event, but as to the auxiliary records, <br>
it really depends on the path the syscall takes through the kernel.


Various <br>
places are hooked and collect information

</span></div><div>Would you have any reference links that would help me understand where these hooks that collect information are placed? <br></div><div><br></div><div>Thanks for the ausearch -i tip. Despite having used that option before, I completely forgot it this time.</div><div><br></div><div>Best Regards,</div><div>Rohit<br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 11, 2022 at 2:47 AM Steve Grubb <<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Monday, January 10, 2022 3:32:55 PM EST Rohit wrote:<br>
> Question 1<br>
> I'm not even sure if this is feasible but does there exist an audit rule<br>
> type <--> record type mapping?<br>
<br>
Nope.<br>
<br>
> For example, a file watch rule for writes and attribute changes (-p wa)<br>
> would generate record types of SYSCALL and CWD. While a watch for execution<br>
> (-p x) on a file would generate a SYSCALL, EXECVE and CWD.<br>
> <br>
> Similarly, is there a way to know what record types the different audit<br>
> rule types (file watches, syscalls) may generate?<br>
<br>
There are 2 kinds of events, simple and compound. The simple events are <br>
typically standalone such as something originating from user space. The <br>
compound events always have a syscall event, but as to the auxiliary records, <br>
it really depends on the path the syscall takes through the kernel. Various <br>
places are hooked and collect information. When the syscall exits, then it <br>
dumps all the collected auxiliary records.,<br>
<br>
<br>
> -----<br>
> <br>
> Question 2<br>
> I am trying to decipher a chmod related log entry. My audit rule is<br>
> -w /etc/passwd -p wa -k passwd_mod<br>
> <br>
> I thereafter ran a "chmod 744 /etc/passwd" . I received a SYSCALL record<br>
> type with the following parameters<br>
> type=SYSCALL msg=audit(1641846347.980:1326): arch=c000003e syscall=268<br>
> success=yes exit=0 a0=ffffffffffffff9c a1=1a600f0 a2=1a4 a3=3c0 items=1<br>
> ppid=6639 pid=6781 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0<br>
> sgid=0 fsgid=0 tty=pts6 ses=4294967295 comm="chmod" exe="/bin/chmod"<br>
> <br>
> I'm trying to decipher whether the above event can give me the exact<br>
> permission passed to the chmod command (755). I understand that execve may<br>
> give it to me easier.<br>
<br>
If you use ausearch -i to look at the raw record, it's much easier.<br>
<br>
type=SYSCALL msg=audit(01/10/2022 15:25:47.980:1326) : arch=x86_64 <br>
syscall=fchmodat success=yes exit=0 a0=AT_FDCWD a1=0x1a600f0 a2=0644 a3=0x3c0 <br>
items=1 ppid=6639 pid=6781 auid=unset uid=root gid=root euid=root suid=root <br>
fsuid=root egid=root sgid=root fsgid=root tty=pts6 ses=unset comm=chmod exe=/<br>
bin/chmod<br>
<br>
> I see the underlying syscall is fchmodat which accepts 3 arguments<br>
> <br>
> int dfd, const char __user *filename, umode_t mode<br>
> <br>
> In which case, in the above log event, would a3=3c0 be the right argument<br>
> to represent the new permission (755)? Or am I reading this incorrectly?<br>
<br>
The a2 argument is the one that has the mode. Ausearch shows that it's value <br>
is 0644.<br>
<br>
-Steve<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Regards<div>Rohit Nambiar</div><div>+91 9008475760</div></div></div></div>