On Tue, Jan 14, 2025 at 11:16 AM Christian Theune <[email protected]> wrote: > > Hi Paul, > > > On 10. Dec 2024, at 20:18, Paul Moore <[email protected]> wrote: > > > > You likely want to look for tty_audit_push() callers, that should help > > identify where/how the kernel decides to flush the TTY data. Looking > > quickly at an upstream kernel I see the following callers: canonical > > mode (as you mentioned), ioctl(TIOCSTI), and the AUDIT_USER_TTY > > command/message from userspace. > > Thanks for those pointers! We sifted through the code but I still have a > question in my head: > do you know (or maybe have another pointer) whether it was an explicit > decision to not > support “\n” scanning in the non-canonical mode? > > My immediate guess: if this was deliberate then maybe because it would be too > much of a performance hit?
I'm sorry, but I don't have a good answer for you, or at least none beyond speculation. I'm much more of a tty user rather than a seasoned tty developer :) While performance *may* be a reason, I suspect modern systems would have no problem handling even the fastest tty data rates while scanning for newlines. I suspect the answer is some combination of wanting to avoid having to parse user input in the kernel as much as possible, and the existence of canonical mode, which does appear to be fairly similar, if not more complex, to what you are describing (assuming I'm understanding your proposal correctly). I also worry about what the audit records would look like if a user were to add a number of escaped newlines to their input stream. Teaching the kernel about various shell escape sequences, and doing all of the associated parsing would be far too ugly to support. > Nevertheless, the current setting of “flush on full buffer” is > counter-intuitively laggy and seems to hit a very high ratio of login > sessions that never manage to fill the buffer. Attackers can easily hide > their traces within even “small” buffers (we’re guessing it’s a page, so > maybe 4k?). Yes, the tty audit buffer is 4k by default and changing it requires modifying the kernel source. I also wonder what odd failures one might see if the buffer size was to change? I would expect that an installation that has strict user auditing requirements would also have other audit filter rules configured to watch for "interesting" events. I would also expect some sort of LSM to be enabled on the system with its own audit events to help identify potentially malicious behavior. > If adding support for scanning for “\n” for the audit flush has a general > chance of being widely interesting then we’d be willing to take a stab at it. > (We’re not experienced kernel developers but are likely dangerous enough to > come up with a patch that might be brought to ripeness with some shepherding > …) First off, I want to commend you for offering to work on a patch, that's excellent! Unfortunately, for some of the reasons mentioned above, I suspect we won't have much luck getting a patch like this accepted upstream. You are welcome to try (although I do worry about the escaped newline issue), and I will be happy to help review and advise as appropriate, but I worry that ultimately it will be rejected. Sorry :/ Perhaps an alternate solution would be to either piggyback on an existing, related commonly used tty ioctl and force an audit tty flush when that ioctl is triggered. If a reasonable candidate can't be found, we could potentially create a new ioctl to force a flush of the audit tty buffer, but that would require userspace modification to fully leverage. -- paul-moore.com
