[LSM/Landlock] Adding ability to sandbox TTYs

[Günther Noack]

Hello!

On Sun, Jun 16, 2024 at 06:02:03PM +0000, COHEN-SCALI Remi (AMPERE) wrote:
> A feature request on landlock is about sandboxing ttys management.

For completeness, this feature request about TTY IOCTL restrictions is at [1].
The idea was originally explained in [2], to protect processes on the same TTY
from messing with each other through the TTY IOCTLs.  In that proposed approach,
the policy decision is guided by the nesting of Landlock domains of the process
and the TTY, similar to how it is decided for ptrace-ability.

[1] https://github.com/landlock-lsm/linux/issues/5
[2] https://lore.kernel.org/all/20230822.ua3aib8Zaile@digikod.net/

> I'd like to propose an api for this feature but before I'd like to hear from
> you about what could be proposed to developers.
>
> Of course the standard approach can be provided for "locking" access to some
> syscalls. It will allow a dev to setup a ttys mngt for his app and then lock
> it. However I think this will not be enough for most of the use case for
> applications making an intensive usage of tty framework.
>
> So I will go first by proposing a standard approach. But in a second step, and
> for also allowing apps having an intensive ttys framework usage to use
> landlock, I think it could be interesting to propose another approach:
>
> something as... providing the app a way to define several configurations and
> allow it to switch from one to another or ...

I'm not sure I follow your proposal there.  I assume that by "configuration" you
mean a Landlock domain (an enforced Landlock ruleset)?  In that case, I don't
see what the advantage of that would be.  -- If an attacker has taken control
over the sandboxed process, they would be able to switch between these
configurations as needed and it would be just as effective security-wise as
having only a single configuration which enforces the lowest common denominator.

Generally, once a Landlock ruleset has been enforced, that enforcement is not
reversable and is inherited to all new subprocesses and threads as well.

Am I missing something?


> PS: I saw @gnoack proposals about this tty handling in landlock and they seems
> to be, at least, a good starting point. I'm also looking at several apps using
> teletypewriter management (gtkterm, minicom, vterm, shells and one I
> specifically love and use, emacs).

The current status quo is that distributions with new kernels are largely
requiring CAP_SYS_ADMIN for the most dangerous TTY IOCTLs which have been used
for privilege escalation in the past.  These IOCTLs are (a) TIOCSTI, as well as
(b) TIOCLINUX with its copy-paste subcommands TIOCL_SETSEL, TIOCL_PASTESEL and
TIOCL_SELLOADLUT.  These patches are independent of Landlock and are already in:

(a) 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")
(b) 8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-paste subcommands")

(This is also documented in tty_ioctl(4) and ioctl_console(2).)

—Günther