Hi We are looking at the FIM capabilities of osquery using l

Question

Hi We are looking at the FIM capabilities of osquery using linux Audit Does osquery use the `a2` field in the syscall audit record to determine if the event was intended for writing eg ```arch=x86 64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffcabc35875 a2=O RDONLY a3=0x0 items=1 ppid=10846 pid=11679 auid= exe= bin cat key=sys bin``` Example this record was emitted by auditd and has a2 field as `O RDONLY` This one was emitted by osquery ```arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=557f5aeb2b90 a2=441 a3=1b6 items=2 ppid=2516 pid=2517 auid= exe= bin bash key= test ``` a2 = 0x441 which is `O WRONLY|O CREAT|O APPEND` showing the intent of writing to a file using tee

theopolis · Answer

< alessandrogario> heads up when you are available

alessandrogario · Answer

The open flags are not reliable as many programs always open with full write access even though they just want to read

alessandrogario · Answer

It will use the write syscalls to determine if something has changed on those files

alessandrogario · Answer

I was however wondering or rather asking for < theopolis> s opinion whether it would be acceptable to do the switch and use the open flags

alessandrogario · Answer

it would mean we no longer have to trace all the write syscalls it s less accurate we can more easily have false positives but should be way better performance wise

theopolis · Answer

to help me understand the tradeoffs better is there a potential for false negative right now for example are we sure we have identified all of the syscalls that might mutate content

theopolis · Answer

I am more in favor of false positives than false negatives but I do think in this case there is abundant use of over requesting access permissions with `open` so the false positive rate might make the writability determination useless

alessandrogario · Answer

I think the biggest problem right now is that unless the machine is on really low activity

alessandrogario · Answer

it s not possible to use the table because all the write system calls will generate a lot of audit records

theopolis · Answer

ah that makes sense

alessandrogario · Answer

mostly because writes are used for everything disappointed

theopolis · Answer

yeah

theopolis · Answer

well if it s a matter of lifting the table from unusable to usable that sounds good slightly smiling face

alessandrogario · Answer

alessandrogario · Answer

in an effort to work around the bogus open flags we implemented tracing on read and write to actually generate events

alessandrogario · Answer

because there are also programs that open files without even reading or writing them

theopolis · Answer

we should make an issue and document the rational for the change so that people can weight in if their expectation is different

theopolis · Answer

is it possible to make this behavior tunable add another flag stuck out tongue

theopolis · Answer

then disable the expensive tracing by default

Prateek Kumar Nischal · Answer

Regarding tracing the `write` syscall the `man 8 auditctl` can implement a FIM rule by ```auditctl w etc p rwxa k key``` This translates to ``` a always exit S all F path= etc k key``` which means it s going to look at all the syscalls that try to do something with the path prefix etc it s recursive An excerpt from the ` p` flag in the man page gt The read amp write syscalls are omitted from this set since they would overwhelm the logs But rather for reads or writes the open flags are looked at to see what permission was requested

Prateek Kumar Nischal · Answer

I saw some SO pages as well that mentioned kauditd is not going emit read and write syscalls since it s going to kill the system with logs I tried looking for a write syscall and I could not generate one using osquery and auditd both as audit clients it would only log `openat` syscall and nothing else when trying to write something into a file

Prateek Kumar Nischal · Answer

The above observation coincides with the docs in auditctl so I am guess the open flags were intended to be used for detecting a write intent

Prateek Kumar Nischal · Answer

PS while allowing osquery to install all 35 syscalls for detecting FIM events osquery just sees an immense amount of logs i was logged into a vm via ssh and osquery debug logs won t stop obviously none of the events were logged but it was processing an absurd amount of events Those syscalls installed don t have any filters and we have been seeing osquery watchdog restarting osquery frequently

Prateek Kumar Nischal · Answer

it may not be relevant but if I open a file with a write flag and not do anything with it the last modified time changes I guess that could be considered as a modification worth considering for the case of stray write flags