teleport
teleport copied to clipboard
gravitational
Updates the directory sharing rfd to include a proposal for audit events
Seems reasonable to me. Only question is whether it is going to be spammy. For example, when copying a large file into or out of the shared directory, will we emit hundreds of read/write events?
How many read/write events are omitted is determined by the program on the Windows machine. In the case of copying files in/out of the shared directory that program is typically File Explorer, which empirically does large read/writes 1MB at a time (exactly 2^20 bytes at a time).
If so, we may want to consider debouncing, or otherwise detecting the last write and only emitting a single event.
Debouncing is difficult to do because we don't have any reliable message coming through that tells us "this sequence of read/writes is done". RDP itself does have a "close file handle" mechanism that works approximately that way, but we handle it in the Rust code and don't translate it into a TDP message. (Now that I understand the system better I realize that it wouldn't be the worst idea to make TDP work more like RDP in this respect, but that's a much larger project).
A couple of options I can see that wouldn't require such a significant refactoring:
- Cache + new TDP message: We cache every read and write near the event emitter, and add a new TDP message that's sent whenever we get an RDP "close file handle" mechanism. Upon receipt, we traverse through the cache and consolidate sequential read/writes for the given file into a single audit event.
- Cache + periodic job: We cache every read and write near the event emitter, and add a function that runs on a timer which traverses the cache, consolidating sequential read/writes to the same file into a single audit event.
Between these two options, I prefer option 1. With option 2, its still possible for what from a human perspective looks like a single large read to get broken up into multiple audit events, if the timer happens to trigger at an inopportune time, whereas this won't happen with option 1 (assuming the Windows side program isn't doing anything weird). Option 1 is also a first step in the larger refactor I mention parenthetically above. The disadvantage of option 1 is that it's a bit more work to add a new TDP message.
It's also of note that by caching read/writes (both options), we open up a greater risk of them not making it into the audit log. IIRC there is some recording mode where the system freezes up if events are not being sent (although I can't seem to find it in the docs) -- such an airtight guarantee would be difficult if not impossible with an event caching system.
Do we really need exact offsets for all read and write ops? We could emit an event for "user has interacted with file" and then maybe emit one with some collected details, periodically/on close.
@espadolini
Do we really need exact offsets for all read and write ops? We could emit an event for "user has interacted with file" and then maybe emit one with some collected details, periodically/on close.
The idea with including offsets is to provide an auditor with as much information as possible without actually logging file data. Your proposal would work too, but requires a more complex implementation for not much of a UX or other benefit as far as I'm able to discern.
The benefit would be to reduce audit log spam while still guaranteeing that at least some info gets in even if Teleport stops abruptly.
The benefit would be to reduce audit log spam while still guaranteeing that at least some info gets in even if Teleport stops abruptly.
Maybe I misunderstood. I thought you were saying to just emit a generic "interacted" whenever we see any of these various actions (read/write/move/delete/etc), and then later emit a summary, but that would be the same amount of events. But I suppose instead you're suggesting that we just add a single event for interaction with any particular file, (and then emit a summary of details on end)?