O firejail depende da falha do aplicativo e por que não podemos usar pipes nomeados para .Xauthority?

Question

O objetivo de prender um aplicativo Xorg é impedir que ele acesse @ / tmp / X11 / X0 e / tmp / X11 / X0 e, em seguida, reutilize seu MIT-MAGIC-COOKIE para roubar de outros aplicativos que estão conectados ao servidor X.

O cookie é usado para obter uma abstração de identificador de arquivo / soquete para o Xorg na primeira vez que o aplicativo se conecta. Se um malvado hacker segmentar o aplicativo e iniciar um shell, ele não terá acesso a essa abstração file-handle / socket e, portanto, precisará do MIT-MAGIC-COOKIE original de .Xauthority E ele precisa acesso ao arquivo / tmp / X11 / X0 / abstract-socket PARA CRIAR um novo CONTEXTO Xorg.

A idéia por trás dos namespaces do FireJail e Linux é esconder esses recursos dele e impedi-lo de criar um novo contexto Xorg.

Para fazer isso, o firejail depende dos Namespaces do Linux e move o aplicativo para um novo namespace, onde / tmp / * não está presente. Ele também fornece ao aplicativo uma nova interface de ponte usando - net = . Portanto, o aplicativo não pode ver um arquivo .Xauthority E não tem como se comunicar com o Xorg. Como o aplicativo está se comunicando através de uma interface de ponte, ele pode ver a internet / supondo que seja permitido, mas sua visão será limitada pelo firewall em br0 etc

O próprio aplicativo usa seu ponteiro de soquete Xorg para falar com o Xorg usando memória compartilhada e SO LONG, pois ele mantém esse ponteiro indefinidamente.

Portanto, a segurança firejail depende do aplicativo ser completamente excluído da memória e LOSING it's XPOR CONTEXT / pointers? Mas o hacker pode se separar no aplicativo e reescrever o código e ainda reter o contexto Xorg? Mas esse é um risco que temos que correr - talvez evitado pelo Apparmor / SELinux e monitorando chamadas do sistema?

No entanto, por que não usamos pipes nomeados ? Crie um named-pipe / .Xauthority e exporte XAUTHORITY e inicie o aplicativo - ele será bloqueado, portanto, na extremidade do servidor, execute algo que grava o cookie atual e o altera assim que o aplicativo for iniciado. Portanto, se o aplicativo se desprender, o hacker é apenas um usuário normal ou restrito, sem nenhum cookie: não há nenhuma esperança no hacker de roubar o novo cookie, especialmente se você limpar / remover o usuário / remover todos os arquivos dele e iniciar de novo a cada aplicativo.

O que o firejail está fazendo que é diferente disso? Se ele precisa que o aplicativo inicie, ele precisa fornecer o arquivo .Xauthority e socket. Então, o que - ele move o aplicativo para um novo NS - como ele sabe quando? Muitos aplicativos pesquisam a autoridade .Xauthority várias vezes, então como o firejail sabe quando ocultar esses recursos e como exatamente ele oculta esses recursos?

    

Answer 1

The purpose of jailing an Xorg application is to prevent it from accessing @/tmp/X11/X0 and /tmp/X11/X0 and then re-using its MIT-MAGIC-COOKIE to steal from other apps that are connected to the X server

Um ... não? Se você ler, por exemplo este guia ,

The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.

Assim, o propósito de se prender um aplicativo X é impedir completamente que ele acesse o servidor principal e, em vez disso, permitir que ele acesse um servidor proxy. Mesmo que o aplicativo tente truques com o servidor proxy, isso não afetará o servidor principal.

Não sei exatamente qual cenário você descreveu, mas qualquer aplicativo X que tenha acesso ao servidor principal de alguma forma, mesmo que a autorização inicial com cookies do MIT não tenha sido feita pelo próprio aplicativo, pode fazer truques nesse servidor, como chave registrando ou acessando outras janelas. Não precisa falhar para fazer isso. Então, fazer a autorização inicial para o aplicativo e, em seguida, impedi-lo de nova autorização não ajuda de forma alguma.

Você possivelmente esqueceu que o ponto principal de iniciar o aplicativo preso de uma maneira particular é fazer com que ele acesse um servidor proxy X?

Editar

I'm just trying to understand what EXACTLY firejail's doing different from traditional xauth/.Xauthority to make the jailed app secure.

Firejail está mostrando ao aplicativo um proxy de servidor X e está impedindo que o aplicativo acesse o servidor X principal. Isso é tudo. O mecanismo xauth tradicional é exatamente o mesmo, tanto entre o aplicativo quanto o proxy X, e entre o proxy X e o servidor X principal. (E sim, é claro que o proxy X precisa acessar o servidor principal, ou, precisa haver um programa que possa acessar tanto o servidor X principal quanto o proxy X. Mas esses programas são > confiável , ao contrário do aplicativo).

and is then relying on Namespaces and to prevent that cookie from being compromised.. and as an added measure hiding the Xorg socket.

Não. O ponto dos namespaces é tornar os terminais de comunicação do servidor X principais inacessíveis. Como em "eles não existem". Não está realmente "escondendo" nada ("está lá, mas você não pode ver"). Não está mais lá, no que diz respeito ao aplicativo preso. Da mesma forma, um contêiner do Docker usa namespaces para fingir que os aplicativos no contêiner estão sendo executados em um ambiente completamente diferente.

Não ter o aplicativo preso ver os terminais de comunicação do servidor X principal já seria suficiente, mas é claro que não há razão para que o aplicativo preso veja cookies MIT válidos para o servidor X principal.

Os pipes nomeados não têm nada a ver com isso. Nem tem falhas. Nem o modo como o mecanismo de autenticação X funciona.

    

Answer 2

Então eu enviei um e-mail para a lista de discussão do Xorg e eles foram muito úteis, então é assim que tudo funciona.

Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local: 0 -seat seat0 vt7 -novtswitch é o comando que você usa para desativar a escuta, exceto em sockets de Domínio UNIX (extraídos do debian).

Isso resultará em / tmp / X11 / X0 e @ / tmp / X11 / X0 soquetes abstratos sendo criados.

O Xorg recebe um cookie sobre esse pipe / socket (escrito pelo programa usando Gtk / Qt - > Xlib [.Xauthority] 1 .

Basicamente, cada aplicativo que escreve para / tmp / X11 / X0 faz com que o Xorg crie um FD exclusivo no final. Se o aplicativo morre e sai, então este FD é fechado pelo Xorg, mas se o aplicativo for injetado, então este Xorg FD / contexto NÃO É destruído e o vírus / aplicativo mal pode falsificar o aplicativo e continuar conversando com o Xorg. Se o aplicativo está usando uma rede / tcp, isso é ainda mais fácil, já que o Xorg apenas usa IP: Port para autenticar após o XOpenDisplay / MIT-COOKIE [o cookie é usado apenas para uma chamada de API para o Xorg].

O aplicativo poderia, se quisesse, manter o COOKIE em sua memória, permitindo que o hacker roubasse o COOKIE, mas esse auth bit é o trabalho do Xlib. A Firejail realmente não se protege contra o roubo de cookies. O que ele faz é usar o Xvfb para renderizar a GUI do aplicativo e enviar o pixmap para o servidor Xorg usando o Xpra - que é dividido em duas partes - um cliente Xpra e um servidor Xpra (o Xpra docs / readme explica esse bit). Porque o servidor só vê o pixmap e nenhuma chamada de API do proxy-confiável / servidor-Xpra / cliente / o que quer que seja protegido por seu Burqa e, portanto, seguro. No entanto, os estupradores ainda estão correndo por aí porque o Xorg é fraco e patético, sem segurança alguma: p

É um monte de fita adesiva segurando tudo junto e não é muito legal e eficiente - embora eu acho muito discutível. O Xorg tem 0 segurança além da verificação de cookie única - foi projetada para uma era diferente, então ... Eu não tenho nada para trabalhar até agora. Eu suspeito que será mais fácil escrever um script bash para fazer o cgroup / resource-limit e namespace ao invés de usar firejail que usa todos os tipos de hacks obscuros e está em C por qualquer motivo. Quanto ao Xorg .. Preciso ler o Xvfb e tentar extrair / enviar os dados para o Xorg através da cadeia.