Hi there, We're currently taking a look at the TTY input logging functionality of the auditing subsystem and evaluating it for use in our environment, however there are some parts of this which we don't quite understand, and we've had difficulty answering our questions purely from reading the kernel sources.
Primarily, it's not clear to us when the kernel decides to flush the keystrokes logged from the TTY into an audit log message which can be read by a userspace process like auditd. As far as we've established in limited testing, the keystrokes read by a given process are only flushed when that process exits. From a security perspective this seems suboptimal, as this would mean that for cases such as a long-running admin shell which runs for several hours the keystrokes would only be logged by the auditing subsystem hours after they occurred. From reading the code we did manage to establish that there's a difference in the input handling when the TTY is in canonical mode. In this case, the kernel provides limited line editing itself, and the TTY input is flushed to the audit logs line by line. In order to do this, the kernel has to actively inspect the buffered input keystrokes to find where the line feed is. However, most shells implement their own line editing and hence don't use canonical mode, which results in the behaviour described above. We're not sure why this difference exists -- presumably there's a good reason why the kernel doesn't inspect the input keystrokes to split the input on line feeds when the TTY is *not* in canonical mode. If you're able to give us some pointers here it would be greatly appreciated. Best wishes, Molly Miller. -- Molly Miller · [email protected] · +49 345 219401 0 Flying Circus Internet Operations GmbH · https://flyingcircus.io Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
