Before I open up a bug w/ osquery upstream, is the...
# kolide
t
Before I open up a bug w/ osquery upstream, is there anything in Kolide's privacy-aware confiuration that might prevent
process_events.env_size
from being populated? I have a query to find short-lived setuid overflow attempts but the field is always NULL. I suspect it's a bug relating to env whitelisting, but wanted to save the osquery maintainers some hassle if it was a known Kolide-specific issue.
This might be my answer on Linux: https://github.com/osquery/osquery/blob/274ea906f96de34d0abd4ed001c178893ffae06a/osquery/tables/events/linux/process_events.cpp#L219 I wonder how that came to be 😞 On macOS, I'm not sure what's going on -- instead of 0, it's always NULL.
s
I don’t think we do anything around that
I would bet it’s used on some platforms, but not others. And/or that it has performance implications. There’s been a fair bit of iteration around this stuff.
On linux, the bpf_process_events may be a better bet.
t
Thanks, I didn't think so but wanted to check first. Based on that hard-coding, I think that auditd on Linux doesn't plumb it through, not sure on macOS.
s
On macos,
es_process_events
is where the API is going, but Kolide doesn’t support the ES tables yet.
t
I take it there is no magical incantation to get Kolide to enable
bpf_process_events
?
It's at least not in https://k2.kolide.com/3361/log_pipeline/osquery_options/edit - so I assume we'll have to wait a bit longer on that to be adopted.
s
I honestly don’t remember. Ping support — adding bpf support shouldn’t be a bit deal, it’s just exposing an option there. The macOS ES support requires a somewhat different codesign path
t
thanks, I'll follow up w/ them.