Unify the event systems

[np5]

Currently, there are three main sources of Santa events:

• SNTStoredEvents created in the SNTExecutionController, and in the SNTBundleService for the SNTEndpointSecurityAuthorizer and buffered in the events.db. Some of those events are used in the GUI to notify the users.
• SNTDeviceEvents created in the SNTEndpointSecurityDeviceManager used in the GUI to notify the users.
• Data (And sometimes SNTStoredEvents) passed to the Logs/EndpointSecurity/Logger to be persisted using one of the available writer/serializer.

The main issue is that the sync servers can only see the SNTStoredEvents.

It would be great for the sync servers but also probably for the maintainability of Santa if there was a unified system to generate, route and ship the Santa events.

One potential pain point is that the SNTStoredEvents are also used to synchronize the Bundle info collection with the sync servers. Also, some of them are shipped as soon as possible to enable some user feedback workflows.

[mlw]

We recently discussed this and I wanted to follow up. As things currently stand, Santa's interaction with the sync server is not really designed to be used this way. The sync server is intended to primarily be used for serving rules and updated configuration. Since rule sets might need to be immediately adaptive, there is support for sending up some basic information about an execution so that the information can be immediately available if a user needs to be served an exception such as for blocked execs. (At Google, we use this for our Upvote-based backend that has been previously presented on). Over time, support was added for sending allowed exec decisions in addition to blocked exec decisions, but we still are only sending a subset of the event information that is logged.

The SNTDeviceEvent is used for sharing data with the UI component over XPC. It, like SNTStoredEvent, is a subset of the information that is logged. Presently, Santa doesn't support fine-grained (i.e. device-specific) USB controls. There hasn't been a push to send these sorts of the events to the sync server since there isn't any information that would be particularly useful for making a decision as to whether or not updated configuration should be sent to the client to allow USB access.

There is a really strong argument that File Access Authorization decisions need to be sent to the sync server since they may require immediate exceptions. This is something we want to do, but haven't yet been able to prioritize it (#1260).

It would be good for us to better document our thinking/expectations around how Santa is designed to interact with a sync service (I've filed: #1326).

It would be great for the sync servers but also probably for the maintainability of Santa if there was a unified system to generate, route and ship the Santa events.

I think from our point of view, a unified event system already exists - and that is the log stream. This supports fully structured output containing the entire set of events that Santa is configured to monitor and unifies everything into a defined schema. Though obviously Santa doesn't provide a log collection mechanism which would need to be done independently. Since it is common in enterprise to need to collect logs from a variety of sources, it makes sense to not have this duplicated code/logic for Santa-specific logs, especially since there are open source solutions that already exist.

---

Is there something about the log stream that isn't working for you? Or maybe other sets of data that you think would be particularly helpful to a sync server when making decisions on new rules to serve?