When scheduling a query, configure the query only to run on devices at or below certain OS version(s) or osquery version

[PenguinzPlays]

For querypacks, set a maximum OS_Version, allowing for us to not deploy to untested os-versions, such as only deploying to catalina vs big sur.

[noahtalerman]

Thank you for the suggestion!

Why is it important to not deploy certain packs/queries on untested os-versions? (Are there performance concerns? Is it generally best practice to test queries on new os-versions before rolling them out?)

[nyanshak]

Not speaking for @kp3nguinz but I also would like this, so I'll share why I would like it.

In Linux, from (not sure minimum version) to 4.5.1, osquery has used the audit subsystem, and you can use process_events table. I'd like to continue to use that for old osquery versions, but on 4.6.0+, query instead on 4.6.0.

I imagine something like:

spec:
  name: my_pack
  queries:
    - name: process_events
      interval: 60
      platform: linux
      query: process_events
      max_version: 4.5.1
    - name: bpf_process_events
      interval: 60
      platform: linux
      min_version: 4.6.0

In this particular case, it's still a bit complicated on my end, because I also have macOS hosts using the process_events query, so I'd likely need to split them into a separately named query / pack for targeting purposes, but the general idea I think is explained above.

[noahtalerman]

Thanks for illustrating your request @nyanshak. I now understand the motivation for setting maximum osquery versions as a method to query different available tables.

We think this request makes sense in terms of the direction Fleet is heading. However, it brings up questions such as "is this functionality built into Fleet vs. built into osquery?"

In the meantime, a current workaround includes using a label query to dynamically target macOS hosts that match the desired version range and then use those labels as pack targets.

[mikermcneil]

@kp3nguinz's suggestion of a filter for scheduled queries is much like what exists today, but instead of just indicating an operating system to filter with when scheduling, this would mean being able to indicate a specific OS version. I could see how this could get complicated and hard to keep up to date with the various flavors of Linux, if we implemented this as a built-in feature in Fleet -- though it would be possible I think. That said, I think @noahtalerman's workaround addresses this in a pinch.

@nyanshak's suggestion is about the same kind of filter, but for osquery version rather than OS version. This would be quicker to implement and take less work to keep up to date (since there's just one set of versions). That said, I think a similar workaround using a label would be possible for this.

[mikermcneil]

Despite the fact that a workaround is possible, I think there is a lot of merit in this use case, especially considering the other functionality coming to Fleet around scheduling.

@zwass Could it make sense to convert today's concept of an OS filter that exists on a per-scheduled-query basis into a more flexible label filter? I think that would enable both of these use cases on a granular, per-query basis that would work for global schedule, team schedule, and additional query packs.

[noahtalerman]

Could it make sense to convert today's concept of an OS filter that exists on a per-scheduled-query basis into a more flexible label filter?

@mikermcneil to make sure I understand, is this suggestion to add the ability to target scheduled queries using labels? (currently can only do this via platform)

[mikermcneil]

@noahtalerman Correct. I think next step here is a feasibility check on whether that approach makes sense (it would mean more qualifier queries getting run on devices.

I'd like to continue to use that for old osquery versions, but on 4.6.0+, query instead on 4.6.0.

@zwass Would there be a way to write SQL such that it short-circuited the tables? Like if bpf_process_events exists, then SELECT from it, otherwise use process_events? (And/or handle differences in columns between the tables?)

If so, then that could be a more generically applicable solution to this problem (and we could write up some docs on how to use this tactic)