feat(daemon): use identities to auth API requests

[benhoyt]

This adds the code to actually use the new state-based identities for API authorization and authentication (part of spec OP043).

The PR updates the daemon to actually use UserState (which now has access-level and UID feilds). The daemon now fetches the request's named identity if one exists, otherwise it populates UserState with default user based on the ucred UID. So UserState is always set -- this makes the access checkers simpler and the notices API code simpler.

If there is a named identity (a non-nil UserState), that identity is used, even if the "default UID-based auth" would let them in. So named identities trump the default ("uid==0 || uid==daemon_uid" means admin; any uid means read). For example, if you have a user bob: {access: untrusted, local: {user-id: 42}} and are making a request with UID 42, it'll only work for untrusted/open endpoints (/v1/health and /v1/system-info), not the usual of any read API.

[hpidcock]

Let's do this one last.

[hpidcock]

@benhoyt I think I want to review this one in isolation after the rest have been merged.

[nishitm]

the changes look good from the security point of view

[hpidcock]

Still reviewing, just some early comments.

[hpidcock]

I'm OK with this special case because it doesn't actually bypass the access checker. As long as we still actually call the access checker, we can have this optimisation.

[thp-canonical]

This should be fine. In case there's another implementation of AccessChecker in the future that is not of concrete type OpenAccess, but behaves the same, we will only "lose" the optimization (meaning we unnecessarily call userFromRequest and populate user properly), but it will still do the right thing.

[hpidcock]

Unrelated flaky test in internals/daemon

----------------------------------------------------------------------
FAIL: api_exec_test.go:91: execSuite.TestStderr

api_exec_test.go:92:
    stdout, stderr, waitErr := s.exec(c, "", &client.ExecOptions{
        Command: []string{"/bin/sh", "-c", "echo some stderr! >&2"},
    })
api_exec_test.go:324:
    c.Assert(err, IsNil)
... value *fmt.wrapError = &fmt.wrapError{msg:"cannot connect to \"control\" websocket: read unix @->/tmp/check-2962214203/23.pebble.socket: i/o timeout", err:(*net.OpError)(0xc000326370)} ("cannot connect to \"control\" websocket: read unix @->/tmp/check-2962214203/23.pebble.socket: i/o timeout")

2024-07-11T05:20:52.589Z [test] Started daemon.
2024-07-11T05:20:52.602Z [test] POST /v1/exec 6.517775ms 202
2024-07-11T05:20:52.607Z [test] GET /v1/tasks/1/websocket/control 3.803267ms 200
2024-07-11T05:20:52.607Z [test] GET /v1/tasks/1/websocket/stdio 101.523µs 200
2024-07-11T05:20:52.608Z [test] GET /v1/tasks/1/websocket/stderr 137.962µs 200
2024-07-11T05:20:52.626Z [test] GET /v1/changes/1/wait 17.87651ms 200

----------------------------------------------------------------------

[hpidcock]

@benhoyt, your work on this is much appreciated.

I've performed the QA that I think was suitable for this (integrating with my Juju PR) + testing the login directly + a series of stress tests on the unit tests (with and without -race).

I am happy to approve this now. I only had one thought around possible security violations that this change could bring and that is to do with revocation of privileges.
If you have a long running request, with an identity that had access to do an action (such as exec, logs, push, pull, etc.), then that action will go uninterrupted, despite changes to the access level for that identity.

We can address that in a future PR.

[flotter]

Really nice!

[benhoyt]

If you have a long running request, with an identity that had access to do an action (such as exec, logs, push, pull, etc.), then that action will go uninterrupted, despite changes to the access level for that identity.

@hpidcock That doesn't really concern me. If you were able to start a long running request, you had access at the time.

[benhoyt]

@thp-canonical Actually, after discussion with Harry, he was a bit concerned with that latest commit to always use Untrusted and a non-nil UserState. It may be good (in future) to distinguish between no auth and an untrusted identity. In addition, both of us had done manual testing on the previous iteration of the code, so any changes now are risky. We can always iterate further in future without user-facing changes.