https://github.com/osquery/osquery logo
Join Slack
Powered by
Hi, We are looking at the FIM capabilities of osqu...
# general
p
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
Copy code
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
Copy code
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)
t
@alessandrogario (heads up when you are available)
a
The open flags are not reliable as many programs always open with full write access even though they just want to read
It will use the *write*() syscalls to determine if something has changed on those files
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
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
t
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?
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
I think the biggest problem right now is that unless the machine is on really low activity
it's not possible to use the table because all the write system calls will generate a lot of audit records
this 1
t
ah, that makes sense
a
mostly because writes are used for everything 😞
t
yeah
well if it's a matter of lifting the table from unusable to usable, that sounds good 🙂
a
in an effort to work around the bogus open flags, we implemented tracing on read() and write() to actually generate events
because there are also programs that open files without even reading or writing them
t
we should make an issue and document the rational for the change, so that people can weight in if their expectation is different
is it possible to make this behavior tunable? add another flag 😛
then disable the expensive tracing by default
p
Regarding tracing the 
write
syscall.. the 
man 8 auditctl
can implement a FIM rule by
Copy code
auditctl -w /etc -p rwxa -k key
This translates to
Copy code
-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.
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..
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”..
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..
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..
2 Views
Open in Slack
PreviousNext
Powered by