Protegendo as janelas X

3

Eu quero instalar o X em um sistema do qual sou responsável. Eu pretendo executá-lo apenas com conexões locais, por exemplo com startx -- -nolisten tcp (o que eu entendo é o padrão nos dias de hoje).

Algumas notas relativamente antigas sobre segurança, Curso de Quebra na Segurança do X Windows , implica que as exibições são inerentemente inseguras:

Running your display with access control enabled by using 'xhost -' will guard you from XOpenDisplay attempts through port number 6000. But there is one way an eavesdropper can bypass this protection. If he can log into your host, he can connect to the display of the localhost. ... Of course, an intruder must have an account on your system and be able to log into the host where the specific X server runs. On sites with a lot of X terminals, this means that no X display is safe from those with access. If you can run a process on a host, you can connect to (any of) its X displays.

A implicação aqui é que não há como fornecer segurança elementar para os displays X localmente.

Isso é verdade? Se não, existem configurações que você precisa considerar para evitar isso?

    
por user1071847 11.04.2016 / 17:07

1 resposta

3

O documento que você está lendo é do século passado. Não me lembro de nenhum sistema que usei neste século que não usasse cookies (descrito no § 8 do documento). Com os cookies, a primeira coisa que um aplicativo precisa fazer quando se conecta ao servidor X é apresentar o “cookie”, que é uma senha que é gerada aleatoriamente quando o servidor é iniciado e armazenado em um arquivo que só você pode ler. Os aplicativos sabem a localização do arquivo de cookie porque é o valor da variável de ambiente XAUTHORITY , com o padrão ~/.Xauthority . Se um processo puder ler seu cookie, significa que ele tem acesso aos arquivos privados da sua conta, portanto, a segurança do servidor X é um ponto discutível.

Como este é o padrão, você não precisa tomar medidas explícitas para proteger o servidor X.

Você precisa evitar alguns comportamentos:

  • Obviamente, não revele o conteúdo do arquivo de cookie.
  • Não use conexões TCP com o servidor X, a menos que elas estejam em uma rede confiável em que você tenha certeza de que não pode haver interceptadores. (A interface de loopback está bem.) Se alguém bisbilhotar na conexão TCP, eles veriam o cookie. Em vez disso, use o SSH e diga-o para encaminhar a conexão X11 ( ForwardX11 yes no arquivo de configuração, ssh -X na linha de comando).
  • Quando você executa o SSH da máquina A (executando um servidor X) para a máquina B, se o encaminhamento do X11 estiver ativado, os aplicativos em execução na sua conta na máquina remota terão acesso ao servidor X local. O servidor X não realiza nenhum isolamento com base na máquina em que o aplicativo está sendo executado. Observe que isso significa que você deve confiar no administrador remoto.

Se um aplicativo tiver acesso ao servidor X, considere que ele tem acesso à sua conta. Embora alguns aplicativos desativem os recursos mais óbvios de monitoração e injeção de teclas, há recursos que não podem ser desativados; X não faz distinção entre um aplicativo de captura de tela, um aplicativo de macro de teclado e algum aplicativo aleatório em que você não confia. Se você deseja executar um aplicativo GUI no qual não confia, execute-o em uma máquina virtual (com a exibição na VM) ou execute-o em uma conta separada e exiba-o em um servidor X separado, como Xnest .

    
por 12.04.2016 / 02:13

Tags