Kolide launcher - Githubissues

znewman01 commented 1 year ago

For work, I (and many others) are required to install Kolide for endpoint security. This is the least-bad endpoint security solution I've ever used. Getting this to work on NixOS is the difference between me using NixOS at work, and switching to another distro[^1]. I imagine other folks are in the same situation. Here's my goal:

[^1]: I also need this installed on my laptop (macOS). While I'd love to manage it via Nixpkgs, this is a lower priority for me, as the normal install works fine. Let me know in the comments if macOS support matters to you.

I can install the Kolide launcher (MIT license) from Nixpkgs.
I can get it running in systemd via a NixOS module (maybe a nix-darwin module too?).
Kolide depends on osquery (dual-licensed: Apache-2.0 and GPL-2.0); I should be able to provide it with an osquery binary using a osqueryPackage configuration parameter in the NixOS module.

Because I need this for work, I'm willing to invest a fair bit of effort here (though help is appreciated), including being a maintainer for osquery and kolide-launcher in Nixpkgs.

Challenges

Osquery

Kolide relies very heavily on osquery. It ships a (not statically linked) copy of the official osquery releases.

osquery used to be in Nixpkgs, but was removed because it broke frequently and there was no maintainer. There are a couple requests to reinstate it (https://github.com/NixOS/nixpkgs/issues/121745, https://github.com/NixOS/nixpkgs/issues/193673) but interest has been low.

Auto-updater

Kolide has its own autoupdater for osquery (and Kolide itself, IIUC). It relies on The Update Framework (TUF) for package signing and metadata distribution. This isn't going to work if we install via Nix :smile: But how do we handle it? How easy will this be to disable? Maintainers should be checking signatures (maybe? if we're building from source, perhaps not). Is there any way to give some of these benefits downstream? So can we check in the Nixpkgs test suite, or even add a checkPhase to the package itself?

I actually happen to know TUF pretty well so if that winds up being an issue here I can help out.

Building

The launcher has its own build tooling. It's relatively simple, but still somewhat nonstandard. There's a couple issues with it when building in Nix:

doesn't use trimpath (so embeds local paths in the binary; not reproducible)
runs Git to get the current revision (no way to override)

Running other binaries

Kolide winds up shelling out to a lot of other tools to query the state of your system. When it does so, it doesn't respect your $PATH; instead, most paths to binaries are hardcoded. This is by design. On NixOS, we don't have ZFS in /usr/bin so the ZFS checks break.

OS-specific stuff

One of the big value-adds of Kolide is that it tracks the installed packages on your OS. However, on NixOS, it doesn't.

This is pretty subtle, actually. What counts as an installed package? In your current system profile? Current user profile? In /nix/store at all? In the store, but pointed to by any GC root?

How I got it kind-of working (warning: terrible hacks)

Install osquery from .deb.
Fork the launcher: https://github.com/znewman01/kolide-launcher
1. Manually check in a (now outdated) copy of the package update metadata.
2. Patch the builder for reproducibility and building in Nix.
3. Patch the hardcoded paths to other tools.
4. Write a flake for local dev and building the package.
Write a module to run it in systemd.

There's a minor subtlety in that you need an "enrollment secret." This is out-of-scope for any NixOS module IMO. I just stuck it in a long-lived directory on my machine; a better solution might use one of the NixOS secret managers.
Enable it in my NixOS config. This was really easy, after the above work!

You should be able to get that setup working for you. Let me know if you need help, though I'd prefer to focus efforts on a long-term solution.

There's one final caveat. Presumably your workplace is making you install Kolide so that it can run a bunch of Osquery checks on your machine. NixOS is weird, and many very standard checks are going to fire because of the way NixOS works. I'm very fortunate to have a friendly and flexible security/compliance manager at my company who is willing to work with me on allow-listing certain NixOS behaviors. If you aren't in that situation, YMMV.

Action plan

[x] Coordinate with the Kolide folks, who are very helpful!
[ ] I need to make update to my fork, including a newer osquery binary.
[ ] Get osquery back into Nixpkgs: https://github.com/NixOS/nixpkgs/issues/193673
[ ] Figure out the autoupdater situation (bonus)
[ ] Upstream fix: send PR for hardcoded paths
[ ] Upstream fix: copy some of my build patches
[ ] Write a Nixpkgs package for the launcher
[ ] Write a Nixpkgs module for the launcher

How you can help!

CC @patflynn @danderson @terlar @joncoll (sorry for the random ping, you're all the folks I could find based on GH issues who care)

GitHub thumbs-ups to let me know if you're interested:
- This issue, if this would be helpful to you!
- Tracking issue for Kolide to support NixOS
- [issue for adding osquery back]()
Volunteer to co-maintain with me! This shouldn't be very much work, mostly reviewing/testing PRs and letting me know when things break.
- osquery
- Kolide launcher (this issue)
Help figure out open questions:
- How should NixOS track installed packages?
- What should we do about the autoupdater?
Volunteer for some of the items in the action plan

nixos-discourse commented 1 year ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/kolide-launcher-in-nixpkgs/22463/1

peterhoeg commented 1 year ago

I suggest having a look at how dropbox is handled in NixOS - that would probably be similar to what you need.

x10an14 commented 1 year ago

I am definitely interested in getting osquery back into nixpkgs for the purposes of kolide, so while my current capacity is reduced, I'm for sure interested in helping out/figuring it out/becoming a maintainer!

Thanks to @ngerstle who pointed me to this issue!