Qual é o propósito das configurações padrão / etc / securetty no Debian?

Question

Eu criei um contêiner instável do Debian com debootstrap e o executei usando systemd-nspawn.service .

Eu consigo logar como root com machinectl login , mas não mais que uma vez ao mesmo tempo. Quando executo o segundo login, ele se recusa assim que eu digito root ; ele não solicita uma senha.

Como você pode esperar, se eu olhar no log do sistema, ele diz que o acesso foi negado por pam_securetty porque o tty /dev/pts/2 "não é seguro". Isso levanta várias questões.

1. como é o primeiro login /dev/pts/0 considerado seguro ??
2. por que /dev/pts/1 não foi usado no segundo login?
3. O padrão / etc / securetty parece listar todos os tipos de tty - incluindo as linhas seriais que podem ser conectadas aos modems ?? Eu posso imaginar razões para excluir pseudo-terminais. Mas, se você vai permitir todos os tipos de terminal físico, qual é o objetivo deste exercício ?! Por que não trabalhar com um conjunto (curto) de tipos tty que não têm permissão para efetuar login como root? Existe alguma coisa que tenha sido deliberadamente omitida da lista, que precisa ser bloqueada por padrão, além dos pseudo-terminais? Se há uma omissão deliberada, então por que não é comentado?

Consegui responder ao primeiro trimestre. A resposta indizivelmente horrível é que no Debian stretch (9-testing, login-4.4-4 ), o / etc / securetty contém / dev / pts / 0 e / dev / pts / 1, mas não / dev / pts / 2. Pode-se adivinhar isso foi adicionado especificamente para suportar systemd-nspawn . E um seria correto . Mas isso só me deixa mais confuso sobre o que essas configurações devem realizar!

    

Answer 1

A implicação é que as configurações não fazem sentido.

Obviamente, uma distribuição que suporte instalações seriadas seria capaz de permitir o primeiro console serial. Sua pergunta é porque o desenvolvedor Debian original pensou que era útil deixar o pam_securetty ativado, mas configurá-lo para permitir todo tipo de tty. E, portanto, o que impediria que uma distribuição usasse uma configuração mais simples.

Poettering sugere uma resposta: as distribuições devem usar uma configuração mais simples, com base no fato de que o sistema de classificação usado pela segurança é obsoleto.

link

It comes from a time where tty names where static. But today the fewest ttys are actual good old mainboard serial ports. Pretty much all of them instead are plugged in via USB or are pseudo ttys. Either way their names are not fixed like /etc/securetty expects it, the entire concept is hence obsolete.

Hence: please ask your distro to stop shipping with pam_securetty enabled by default, it's really a thing of the past. In the meantime remove it manually from all files in /etc/pam.d/* or add all your potential current and future ptys to /etc/securetty.

link

You could just delete /etc/securetty from the container which will allow root login on all ttys.