latchset / crypto-auditing Goto Github PK

Similarly to TLS context names and TLS events, we should define IPsec (IKE) specific context names and events.

It would be nice if the crypto-auditing-event-broker service is activated through a socket. This would require constructing UnixStream from an FD received with receive_descriptors in the libsystemd crate.

It would make sense to define some probe points for generic crypto operations, in a protocol agnostic way, for example:

• pk::sign, pk::encrypt, pk::decrypt, aead::encrypt, aead::decrypt context names
• hash::algorithm, pk::algorithm, pk::key_size, aead::algorithm events

Maybe we could use OID for *::algorithm events if it is not too much burden to parse.

It would be useful if the agent can be compiled without support for io_uring, which is currently a hard requirement.

It would be nice to collect library names where probes are instrumented. This could be done in the following steps:

• The BPF program reports PID and the topmost symbol address obtained with bpf_get_stack(..., BPF_F_USER_STACK)
• The agent reads the /proc/$PID/map_files directory and finds the library which is loaded and mapped to a memory area containing the symbol address

As this may affect performance, a caching mechanism would be desired.

It would be nice to create a client that feeds events directly to Grafana as a data source when they arrive.

tokio_uring::fs::write_at tries to write the entire content of buffer but the entire write may fail. It would be nice to schedule retry in that case.

This is not the case with tokio::io::AsyncWriteExt::write_all.

Similarly to TLS context names and TLS events, we should define SSH specific context names and events.

We currently only have a couple of unit tests. It would be nice to have integration tests that exercise communication between the components (agent, event-broker, and client).