TTY restrictions

[l0kod]

TTY's IOCTL commands such as TIOCSTI and TIOCLINUX can be abused since a few decades:

• https://isopenbsdsecu.re/mitigations/tiocsti/
• https://jdebp.uk/FGA/TIOCSTI-is-a-kernel-problem.html

The situation has improved with 83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d and 8d1b43f6a6df7bcea20982ad376a000d90906b42 though. However, these system-wide restrictions are not enforced per sandbox, which means developers cannot safely protect their applications without impacting the whole system. Making Landlock able to protect against this kind of attack and other TTY-based ones (e.g. snoop keystrokes) is definitely something worth it.

Basically, all IOCTLs that enable, one way or another, to fool a user should be restricted as TIOCSTI. This includes copy/paste requests (TIOCLINUX subcommands), but also potentially font change (e.g. PIO_FONT), keyboard mapping change, all CAP_SYS_TTY_CONFIG-checked IOCTLs, and probably more. The goal is not to protect against potentially annoying features such as keyboard light changes though, but really to protect integrity and confidentiality of data going through the TTY.

The goal is to enforce Landlock security boundaries across TTY's clients. In a nutshell, if a process is sandboxed, only allow read, write and most IOCTL requests if the TTY's domain would be ptracable, otherwise deny such action. I think this algorithm would fit well:

• if the current process is not sandboxed, then allow
• else if the TTY's domain is the same or a child of the current process's domain, then allow (including the TIOCSTI IOCTL)
• else if the current process is the session leader of this TTY, then allow read/write/non-TIOCSTI-IOCTLs
• else deny

The challenge would be to make these checks efficient, especially for the read and write syscalls.

A new set of LSM hooks dedicated to TTY drivers should help (see file_operations variables in drivers/tty/tty_io.c), but what about out-of-tree drivers?)

See https://lore.kernel.org/all/20230822.ua3aib8Zaile@digikod.net/

[l0kod]

Another interesting bypass with TIOCL_SETSEL from @jwilk: https://www.openwall.com/lists/oss-security/2024/01/16/5

TIOCL_SETSEL selects text on the active vt, even when the fd you ran ioctl on refers to a different vt. Since switching virtual terminals doesn't require extra privileges, if /dev/ttyN is your controlling terminal, you can select text from any otherwise inaccessible vt, and then paste it into your own program.

The main issue is that an IOCTL command may not be relative to the FD on which it is send, but relative to the current console...

Cc @gnoack

[gnoack]

Another interesting bypass with TIOCL_SETSEL from @jwilk: https://www.openwall.com/lists/oss-security/2024/01/16/5

Just to clarify, TIOCL_SETSEL is one of the TIOCLINUX subcommands which was addressed by Hanno Böck's patch in https://github.com/landlock-lsm/linux/commit/8d1b43f6a6df7bcea20982ad376a000d90906b42

[rcoscali]

Hi again I'm looking at #10 and also this one for starting to dig into the code. #7 has already an active hacker (it seems). I like ttys and I made an port of virtual ttys on minix when I first saw in linux in 90's. #10 seems a little bit more complicated because of perf & UDP semantic... I'll try to send a proposal for covering ttys ... We'll chat about it at this moment

[l0kod]

Hi again I'm looking at #10 and also this one for starting to dig into the code.

Good! Proper TTY restriction is tricky, and getting an efficient design is challenging. Please take a look at the related mailing list discussions linked in this issue.

7 has already an active hacker (it seems).

Yes

I like ttys and I made an port of virtual ttys on minix when I first saw in linux in 90's. #10 seems a little bit more complicated because of perf & UDP semantic... I'll try to send a proposal for covering ttys ... We'll chat about it at this moment

If you're comfortable with TTY, it should be a good pick. FYI, @gnoack spent some time on this topic.