On Fri, Jun 27, 2025 at 06:38:42PM -0600, Abhinav Saxena wrote:
As noted in previous discussion, while CONFIG_LEGACY_TIOCSTI can restrict TIOCSTI usage, it is enabled by default in most distributions. Even when CONFIG_LEGACY_TIOCSTI=n, processes with CAP_SYS_ADMIN can still use TIOCSTI according to the Kconfig documentation.
Additionally, CONFIG_LEGACY_TIOCSTI controls the default value for the dev.tty.legacy_tiocsti sysctl, which remains runtime-configurable. This means the described attack vector could work on systems even with CONFIG_LEGACY_TIOCSTI=n, particularly on Ubuntu 24.04 where it’s “restricted” but still functional.
What is the threat scenario that you are concerned about? The concern with TIOSTI is that it is a privilege escalation mechanism. But you need to have root (well, CAP_SYS_ADMIN) to either enable the dev.tty.legacy_tiocsti sysctl, or to use TIOCSTI. So what's the privilege escalation that you're concerned about?
I could imagine some fairly esoteric ways that this might be a problem, but if it's not a common case concern, maybe using some kind of LSM to more forcibly disable TIOCSTI is sufficient?
Yes, we could imagine ways in which it could be permanently disabled (perhaps via a boot command line option) such that it can't be re-enabled without rebooting. But is the extra complexity worth it, especially when there is always the LSM solution for the super-paranoid sysadmins?
- Ted