it would be nice if these strings (records in this...
# corem
marpaia
03/27/2018, 8:59 PMit would be nice if these strings (records in this case) things could immediately be passed to the logging subsystem. kind of like https://github.com/facebook/osquery/pull/3482 but not specific to tls.
a
alessandrogario
03/27/2018, 9:02 PM
Didn’t know you could do this, I’ll look into it. Would this become something that you toggle on and off or something that is always enabled (removing the table)?
m
marpaia
03/27/2018, 9:08 PMi would love to just be able to configure a subscription to an event publisher via options and get a stream of logs to the logger plugin
marpaia
03/27/2018, 9:08 PMmaybe as a new event type
marpaia
03/27/2018, 9:09 PMthe best you can do now is
select *removed: falsemarpaia
03/27/2018, 9:09 PMbut that still has to go through the interval of the scheduler, diff logic after getting the results out of rocksdb, etc
marpaia
03/27/2018, 9:12 PMrocksdb should still be involved for the durability of process restarts, network failure, etc but i think a lot of the rest of it can be peeled back and added to the logging subsystem directly in a plugin agnostic way
a
alessandrogario
03/27/2018, 9:13 PM
uhm so each log line would be a complete row?
m
marpaia
03/27/2018, 9:13 PMeither a
RowQueryDataa
alessandrogario
03/27/2018, 9:15 PM
That would be cool, and would probably speed up a lot of simple tables
m
marpaia
03/27/2018, 9:16 PMyeah, i think it would work well for higher throughput event publishers
marpaia
03/27/2018, 9:16 PMprobably a micro-optimization for something like
usb_devicesmarpaia
03/27/2018, 9:17 PMbut for audit or ebpf, it seems like it would be a fair bit more efficient to marry these two systems together
6 Views