Title
#general
p

Prateek Kumar Nischal

12/17/2020, 4:59 PM
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

theopolis

12/18/2020, 3:35 AM
@alessandrogario (heads up when you are available)
a

alessandrogario

12/18/2020, 12:01 PM
The open flags are not reliable as many programs always open with full write access even though they just want to read
12:02 PM
It will use the write() syscalls to determine if something has changed on those files
12:03 PM
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
12:04 PM
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

theopolis

12/18/2020, 2:54 PM
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?
2:56 PM
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.
a

alessandrogario

12/18/2020, 2:57 PM
I think the biggest problem right now is that unless the machine is on really low activity
2:57 PM
it's not possible to use the table because all the write system calls will generate a lot of audit records
:this: 1
theopolis

theopolis

12/18/2020, 2:57 PM
ah, that makes sense
a

alessandrogario

12/18/2020, 2:58 PM
mostly because writes are used for everything 😞
theopolis

theopolis

12/18/2020, 2:58 PM
yeah
2:58 PM
well if it's a matter of lifting the table from unusable to usable, that sounds good 🙂
2:59 PM
in an effort to work around the bogus open flags, we implemented tracing on read() and write() to actually generate events
2:59 PM
because there are also programs that open files without even reading or writing them
theopolis

theopolis

12/18/2020, 2:59 PM
we should make an issue and document the rational for the change, so that people can weight in if their expectation is different
3:00 PM
is it possible to make this behavior tunable? add another flag 😛
3:00 PM
then disable the expensive tracing by default
p

Prateek Kumar Nischal

12/18/2020, 10:23 PM
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.
The read & 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.
10:25 PM
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..
10:26 PM
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”..
10:29 PM
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..
10:34 PM
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..