[LSM/Landlock] Adding ability to sandbox TTYs

[LSM/Landlock] Adding ability to sandbox TTYs

[COHEN-SCALI Remi (AMPERE)]

Hi

A feature request on landlock is about sandboxing ttys management. 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 ...

Have you got ideas for this ... I can't wait hearing from you if you have ideas about ...

Thanks

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).

Rc5kali

Confidential C
-- Disclaimer ------------------------------------ 
Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme.

*** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.

Re: [LSM/Landlock] Adding ability to sandbox TTYs

[Greg KH]

On Sun, Jun 16, 2024 at 06:02:03PM +0000, COHEN-SCALI Remi (AMPERE) wrote:
> *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.

Now deleted.

Re: [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