I have a `file` query that I would like to be able...
# general
t
I have a
file
query that I would like to be able to recurse directories that begin with a '.' (hidden), but I can't figure out the right magic incantation for the life of me. For example, if you run this to prepare the test:
Copy code
mkdir -p /tmp/.out/.omg && cp /bin/ls /tmp/.out/.omg
You can find this file in osquery using:
Copy code
SELECT path FROM file WHERE file.directory = '/tmp/.out/.omg';
But how would I find it without knowing what subdirectories in /tmp that it's part of? Ideally I'd love '/tmp/%%' to have returned it, but it doesn't include directories that begin with a dot. This also returns zero result:
Copy code
SELECT path FROM file WHERE file.directory = '/tmp/.%/.%';
As does:
Copy code
SELECT path FROM file WHERE file.directory = '/tmp/.out/.o%';
macOS & Linux both behave similarly, using osquery 5.7.0.
I did skim through these articles again but neither seemed to mention the observed behavior: • https://www.kolide.com/blog/the-file-table-osquery-s-secret-weaponhttps://www.uptycs.com/blog/wildcards-and-globbing-in-osquery
s
thinks Yeah, I recall some conversation, somewhere, about how it doesn’t traverse through the dot directories. I don’t know if there’s a workaround.
t
Funny enough, the issue was fully between the seat and the keyboard. I accidentally switched to using
=
instead of
LIKE
when doing the hidden directory tests. This works:
Copy code
SELECT path FROM file
WHERE
file.directory LIKE '/tmp/.%/.%'
AND NOT file.directory LIKE '%/../%'
AND NOT file.directory LIKE '%/./%';
It's awkward to add the second two filters, but otherwise you end up with a lot of weird content entries, like
/tmp/././out
and
/tmp/../../etc
Here's the query I was refactoring to try to speed up: https://raw.githubusercontent.com/chainguard-dev/osquery-defense-kit/main/detection/evasion/unexpected-tmp-executables-macos.sql I managed to make it 50% faster, but that was likely more due to me restricting the recursion depth than subquery trickery.
s
I can’t really absorb this, but I wonder if you’d do better with a regex there.