Investigate running our agent as a per-user process

[directionless]

As we've developed Desktop, it has become clear that (at least on macOS) the platform expectation is that we run as a user specific launcher agent. This comes up in many ways:

1. Secure Enclave access in in the user context
2. Sending notifications is in the user context
3. Systray is in the user context

And, with the shift to Device Trust, we have a path for working in user context. Namely, if you want access to resource, you need to run our agent.

Thus, it behooves us to understand whether we can run our agent entirely in user context. Or maybe just primarily. 🤷 Research needed. Initial questions:

1. If we run in user context, how do we get access to things like the TCC database? Are there other things we need root for? Can we sudo?
2. Would we end up with a root component? How do they talk? Maybe they don't, and they just leave some signed messages?
3. What does it look like if we're running as multiple users? If the user locked and another logged in, are they both active?
4. What about other platforms? What are the expectations on windows and linux?

[James-Pickett]

Testing running Kolide launcher as a LaunchAgent by putting .plist config in /Library/LaunchAgents as well as ~/Library/LaunchAgents. As we have discovered in the past, this lets us access the secure enclave. It also inherits the Full Disk Access of the .app if set. So we can access the TCC database.

However, it does not provide the sudo / root access we need for tables such as kolide_apple_silicon_security_policy. I have not found any feasible path to getting a launch agent to run with as sudo.

[James-Pickett]

Did a test where I set up a launch daemon (to make sure I was in the root ctx) that ran the following script:

the script is intended for testing purposes only

#!bin/bash
/bin/launchctl asuser 501 sudo --preserve-env -u jamespickett /usr/local/kolide-k2/bin/launcher --config=/Users/jamespickett/Documents/kolide-k2-test/k2device-preprod.kolide.com/launcher.flags

launch daemon plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>run.launcher</string>
        <key>Program</key>
        <string>/Users/jamespickett/Documents/repos/launcher-runner/runlauncher.sh</string>
        <key>RunAtLoad</key>
        <true/>
        <key>StandardErrorPath</key>
        <string>/Users/jamespickett/Documents/repos/launcher-runner/stderr.log</string>
        <key>StandardOutPath</key>
        <string>/Users/jamespickett/Documents/repos/launcher-runner/stdout.log</string>
    </dict>
</plist>

this ran launcher and in this context launcher was able to:

access secure enclave access privileged tables like apple_silicon_security_policy

[James-Pickett]

Did a test on macos:

• Created user Alice
• Created user Bob
• Logged in as Bob
• Logged in as root (could not figure out how to first time login as root, had to login as Bob then switch user)
• Ran the test binary created by this command using the following:

  /bin/launchctl asuser 501 sudo --preserve-env -u Alice $test_binary_path

I was able to access the secure enclave as Alice (who never logged in)

Maybe important to note that the binary was signed with macos development keys, it's possible this will behave differently with a "properly" signed binary.

[directionless]

This is mostly long term research. I'm closing this issue, since it's not an active project. Parts of it survive in PRs