Auth: Events that are not project specific can be viewed by all authenticated client

[markylaing]

• In all of 5.0/stable, 5.20/stable and 5.21/stable and in edge, a restricted TLS client will see lifecycle and operation events that are not tied to a project.
• All invocations of events.SendLifecycle are adding a project (the default project in many cases). Even when the entity for which the lifecycle event is emitted is not project specific, such as certificates, identities, auth groups, etc.
• Many operations are not passing in a project, when those operations emit events, they can be seen by restricted TLS clients.
• All logging events are considered privileged, so these cannot be viewed by a restricted TLS client (they also are not project specific).
• In edge, an OIDC user with no permissions is able to view the operations that are not project specific.
• As far as I can tell, the operations which are not project specific are cluster wide tasks like refreshing instance types, image refresh/cleanup, cluster bootstrap/join, creating auto snapshots and so on.

This means that the recent changes to permissions handling hasn't caused a regression. In fact, allowing OIDC users to view events that are not associated with a project is more in-keeping with the current functionality. However, I think this is quite problematic because a) it's not clear when e.g. sending a lifecycle event that the project must be specified or else unrestricted clients can see it, and b) I'm not confident that we're not going to break things if we change it.

The problematic line is here (stable-5.0):

lxd/lxd/events/events.go

Lines 177 to 180 in b8c2121

	// If the event is project specific, check if the listener is requesting events from that project.
	if event.Project != "" && !listener.allProjects && event.Project != listener.projectName {
	continue
	}

When refactoring the events handler for fine-grained auth, another check was added here:

lxd/lxd/events/events.go

Lines 191 to 194 in e51b0a8

	// If the event is project specific, ensure we have permission to view it.
	if event.Project != "" && !listener.projectPermissionFunc(entity.ProjectURL(event.Project)) {
	continue
	}

In both cases, events are only filtered out if the event itself is associated with a project, but there is no authorization check if the project is not set on the event.

We should review which events should be seen by which clients and how to prevent events that are restricted from being viewed by unprivileged clients.

[tomponline]

@markylaing does #13962 supersede this?

[markylaing]

@markylaing does #13962 supersede this?

It's related but a solution to #13962 might not solve this. We need to decide who should be able to see these background operations. There are no current restrictions on it. If we take Option 4. from #13962 we could just add the server URL to the event, since everyone has can_view on server there would be no change in behaviour, but we would at least have a concrete definition for who can see these events.