Software inventory: See last time Linux software was used

[ddribeiro]

• customer-numa: Gong snippet: Customer does not allow call recordings
• @noahtalerman: User requested this because they want to replace the Flexera agent with the Fleet agent on Linux hosts and need last_opened_at data to support software usage tracking in Flexera. This way, they can answer these questions:
  • DEX: Who's actually using the app? This way, we can decide how to support the app. For example, when a new vulnerability comes out, do we provide documentation/training on how to delete it or update it?
  • DEX: Maybe we can provide docs to help the few people that are using it?
  • Do we have too many Parallels licenses? Who's actually using it?
  • @noahtalerman: In the interim they might be able to run customer PowerShell scripts to get this data.
    • @allenhouchins: Users could also get this info for third-party apps by looking at login data from the third-party software.
  • @noahtalerman: Eventually Fleet could collect and return last_opened_at timestamps for software on Linux hosts via the GET /api/v1/fleet/hosts/:id endpoint.

---

[noahtalerman]

The GET /api/v1/fleet/hosts/:id API endpoint returns a last_opened_at timestamp for macOS hosts. Linux hosts do not have this timestamp.

customer-numa uses Flexera for software asset management. Rather than deploy the Flexera agent, they would like to just deploy the Fleet agent and build a connector to get the relevant information into Flexera. last_opened_at for Linux hosts is something numa would need from Fleet today in order to accomplish that.

This is similar to #27087, but for Linux.

What have you tried?

I made a GET /api/v1/fleet/hosts/:id API call to a Linux host to try to get last_opened_at timestamps for installed software. However, none of the objects in the software array in the response contained a last_opened_at property.

Potential solutions

Fleet would need to identify a way to reliably collect the last opened time for applications on Linux hosts, then return that timestamp on a per-host basis in the API response.

What is the expected workflow as a result of your proposal?

customer-numa would use the Fleet API to build a Flexera connector. They would deploy the Fleet agent to their Linux hosts and would not deploy the Flexera agent. The connector would call the Fleet API to ingest all relevant information into Flexera, including the last time an application was opened on a host.

[iansltx]

Heads-up: the only data source where we currently support last_opened_time, for any platform, is macOS apps (and only apps; other macOS sources like homebrew packages don't include a last opened time). The column is is implemented here, which looks to collect the last opened time for the app directory I believe, which works because that's how macOS apps work.

Our Linux software detail query pulls from DEB packages, RPM packages, Chrome extensions, Firefox addons, Python packages (via an additional query), NPM packages, and Portage packages. Of those, npm/Chrome/Firefox/Python packages include installed paths; the others don't. rpm_package_files could likely be joined to rpm_packages to get package paths there, but an equivalent table doesn't exist for deb_packages.

For cases where we can access installed paths, we could probably join against file to get atime, though that would give us one entry per package file rather than a higher-certainty "this app was opened last at X time," and I'm not sure what performance looks like on that since you'd wind up stat'ing a large percentage of a machine's file system to pull the data.

For at least package types that don't have installed paths (deb_packages being the big one), we'd need to do osquery changes of some sort no matter what to get either package files or a more opinionated last-opened time...and we'd need to do this for each table that we want to extract from.

Given the above, first step seems like it would be to confirm that relevant software is being inventoried (counterexample: snap packages). Next, for a representative double-handful of Linux software, determine what the "correct" last opened time is and how to programmatically get that. Then figure out a fast/light/consistent way of pulling that data, determine how that should be exposed in osquery, and add the missing functionality (again, for deb package we'll have to add something no matter what).