Access to terminals and program isolation

[beroal]

Do I understand correctly that if a program has access to /dev/tty* and /dev/pts/*, then it has access to terminals that other programs are using? For example, the program can send a command to another program or read a password sent to another program.

[roddhjav]

Not exactly, tty only get inputs from your keyboard and send it to a program. Therefore, the terminal itself (the shell, the pipes, the program output) cannot be observed by reading on /dev/pts/*.

However, by looking at /dev/pts/*one can intercept everything that is entered by a user. With one limitation: due to the master/slave nature of pts, if an attacker program reads someone else tty, the targeted program will never see any input.

Finally, https://gitlab.com/apparmor/apparmor/-/issues/92 sums up the stage of console mediation in apparmor.

[beroal]

Interestingly, Linux namespaces can isolate terminals. If a command is executed with

bwrap --dev-bind / / --tmpfs /dev -- $COMMAND

it can communicate via the standard streams, but it isn't allowed to open /dev/tty* or /dev/pts/*.

[beroal]

I would like to know the policy of this project regarding TTY access so I can contribute correctly. What permissions should be granted to the following programs?

• a GUI program that prints a log to stdout
• a TUI program that communicates with the user via stdin and stdout

[beroal]

I ask because I experience #480 with other programs. If you add permitlssions on a case-by-case basis, people will try new programs in the console and file bug reports endlessly.

Here is my opinion on this. Some programs use the standard streams (stdout and friends in C) to communicate with users or write logs. Probably, some don't. If a program is executed in a virtual terminal, its standard streams refer to /dev/tty@{int}. If a program is executed in a terminal emulator, its standard streams refer to /dev/pts/@{int}. At least, this is how my Arch Linux system works. A non-GUI program may be executed in a virtual terminal or in a terminal emulator. A GUI program is executed in a terminal emulator. Theoretically, you can execute a GUI program in a virtual terminal, but nobody does it. So programs need the following permissions.

GUI program, doesn't use the standard streams:

deny /dev/pts/@{int} rw,

GUI program, uses the standard streams:

/dev/pts/@{int} rw,

Non-GUI program, doesn't use the standard streams:

deny /dev/tty@{int} rw,
deny /dev/pts/@{int} rw,

Non-GUI program, uses the standard streams:

/dev/tty@{int} rw,
/dev/pts/@{int} rw,

[beroal]

The programs pavucontrol-qt and transmission-qt require access to both /dev/pts/@{int} and /dev/tty to write a log to console. Weird.

[roddhjav]

That is normal: a lot of UI program still call some command line tool internally. Therefore they often need a tty. So Blocking console to all UI program won't work at all.

[beroal]

What do you mean by “internally”? If it's a child process, I will see it.

[roddhjav]

Usually it it through a shell, but it does not has to be.