All of lore.kernel.org
 help / color / mirror / Atom feed
* Mapping of Audit rule to Record Type Generated + chmod log query
@ 2022-01-10 20:32 Rohit
  2022-01-10 21:17 ` Steve Grubb
  0 siblings, 1 reply; 4+ messages in thread
From: Rohit @ 2022-01-10 20:32 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 1556 bytes --]

Hello!

I have two questions. I had a quick search through the mailing archives
before posting here.

-----
Question 1
I'm not even sure if this is feasible but does there exist an audit rule
type <--> record type mapping?

For example, a file watch rule for writes and attribute changes (-p wa)
would generate record types of SYSCALL and CWD. While a watch for execution
(-p x) on a file would generate a SYSCALL, EXECVE and CWD.

Similarly, is there a way to know what record types the different audit
rule types (file watches, syscalls) may generate?

-----

Question 2
I am trying to decipher a chmod related log entry. My audit rule is
-w /etc/passwd -p wa -k passwd_mod

I thereafter ran a "chmod 744 /etc/passwd" . I received a SYSCALL record
type with the following parameters
type=SYSCALL msg=audit(1641846347.980:1326): arch=c000003e syscall=268
success=yes exit=0 a0=ffffffffffffff9c a1=1a600f0 a2=1a4 a3=3c0 items=1
ppid=6639 pid=6781 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts6 ses=4294967295 comm="chmod" exe="/bin/chmod"

I'm trying to decipher whether the above event can give me the exact
permission passed to the chmod command (755). I understand that execve may
give it to me easier.
I see the underlying syscall is fchmodat which accepts 3 arguments

int dfd, const char __user *filename, umode_t mode

In which case, in the above log event, would a3=3c0 be the right argument
to represent the new permission (755)? Or am I reading this incorrectly?

---

Thanks so much for the help!
Regards
Rohit

[-- Attachment #1.2: Type: text/html, Size: 2519 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Mapping of Audit rule to Record Type Generated + chmod log query
  2022-01-10 20:32 Mapping of Audit rule to Record Type Generated + chmod log query Rohit
@ 2022-01-10 21:17 ` Steve Grubb
  2022-01-11  6:37   ` Rohit
  0 siblings, 1 reply; 4+ messages in thread
From: Steve Grubb @ 2022-01-10 21:17 UTC (permalink / raw)
  To: linux-audit; +Cc: Rohit

Hello,

On Monday, January 10, 2022 3:32:55 PM EST Rohit wrote:
> Question 1
> I'm not even sure if this is feasible but does there exist an audit rule
> type <--> record type mapping?

Nope.
 
> For example, a file watch rule for writes and attribute changes (-p wa)
> would generate record types of SYSCALL and CWD. While a watch for execution
> (-p x) on a file would generate a SYSCALL, EXECVE and CWD.
> 
> Similarly, is there a way to know what record types the different audit
> rule types (file watches, syscalls) may generate?

There are 2 kinds of events, simple and compound. The simple events are 
typically standalone such as something originating from user space. The 
compound events always have a syscall event, but as to the auxiliary records, 
it really depends on the path the syscall takes through the kernel. Various 
places are hooked and collect information. When the syscall exits, then it 
dumps all the collected auxiliary records.,


> -----
> 
> Question 2
> I am trying to decipher a chmod related log entry. My audit rule is
> -w /etc/passwd -p wa -k passwd_mod
> 
> I thereafter ran a "chmod 744 /etc/passwd" . I received a SYSCALL record
> type with the following parameters
> type=SYSCALL msg=audit(1641846347.980:1326): arch=c000003e syscall=268
> success=yes exit=0 a0=ffffffffffffff9c a1=1a600f0 a2=1a4 a3=3c0 items=1
> ppid=6639 pid=6781 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts6 ses=4294967295 comm="chmod" exe="/bin/chmod"
> 
> I'm trying to decipher whether the above event can give me the exact
> permission passed to the chmod command (755). I understand that execve may
> give it to me easier.

If you use ausearch -i to look at the raw record, it's much easier.

type=SYSCALL msg=audit(01/10/2022 15:25:47.980:1326) : arch=x86_64 
syscall=fchmodat success=yes exit=0 a0=AT_FDCWD a1=0x1a600f0 a2=0644 a3=0x3c0 
items=1 ppid=6639 pid=6781 auid=unset uid=root gid=root euid=root suid=root 
fsuid=root egid=root sgid=root fsgid=root tty=pts6 ses=unset comm=chmod exe=/
bin/chmod

> I see the underlying syscall is fchmodat which accepts 3 arguments
> 
> int dfd, const char __user *filename, umode_t mode
> 
> In which case, in the above log event, would a3=3c0 be the right argument
> to represent the new permission (755)? Or am I reading this incorrectly?

The a2 argument is the one that has the mode. Ausearch shows that it's value 
is 0644.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Mapping of Audit rule to Record Type Generated + chmod log query
  2022-01-10 21:17 ` Steve Grubb
@ 2022-01-11  6:37   ` Rohit
  2022-01-11 15:42     ` Steve Grubb
  0 siblings, 1 reply; 4+ messages in thread
From: Rohit @ 2022-01-11  6:37 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 3166 bytes --]

Hello Steve,

Thank you, that's very helpful.

> The compound events always have a syscall event, but as to the auxiliary
records,
it really depends on the path the syscall takes through the kernel. Various
places are hooked and collect information
Would you have any reference links that would help me understand where
these hooks that collect information are placed?

Thanks for the ausearch -i tip. Despite having used that option before, I
completely forgot it this time.

Best Regards,
Rohit


On Tue, Jan 11, 2022 at 2:47 AM Steve Grubb <sgrubb@redhat.com> wrote:

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

-- 
Regards
Rohit Nambiar
+91 9008475760

[-- Attachment #1.2: Type: text/html, Size: 4176 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Mapping of Audit rule to Record Type Generated + chmod log query
  2022-01-11  6:37   ` Rohit
@ 2022-01-11 15:42     ` Steve Grubb
  0 siblings, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2022-01-11 15:42 UTC (permalink / raw)
  To: Rohit; +Cc: linux-audit

On Tuesday, January 11, 2022 1:37:18 AM EST Rohit wrote:
> Hello Steve,
> 
> Thank you, that's very helpful.
> 
> > The compound events always have a syscall event, but as to the auxiliary
> 
> records,
> it really depends on the path the syscall takes through the kernel. Various
> places are hooked and collect information
> Would you have any reference links that would help me understand where
> these hooks that collect information are placed?

They start somewhere in this general area:
https://elixir.bootlin.com/linux/latest/source/include/linux/audit.h#L330

There are many hooks. The auxiliary record types are in the 1300 block:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L89

The one exception is AUDIT_REPLACE which was mistakenly placed in this block. 
It should have been in the 1000 block.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-11 15:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-10 20:32 Mapping of Audit rule to Record Type Generated + chmod log query Rohit
2022-01-10 21:17 ` Steve Grubb
2022-01-11  6:37   ` Rohit
2022-01-11 15:42     ` Steve Grubb

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.