Xorg 애플리케이션을 감옥에 가두는 목적은 해당 애플리케이션에 대한 액세스를 방지하는 것입니다.@/tmp/X11/X0그리고/tmp/X11/X0그런 다음 재사용하세요.MIT 매직 쿠키X 서버에 연결된 다른 응용 프로그램에서 훔칩니다.
이 쿠키는 애플리케이션이 처음 연결될 때 Xorg의 파일 핸들/소켓 추상화를 얻는 데 사용됩니다. 악의적인 해커가 애플리케이션을 세그폴트하고 셸을 시작하면 이 파일 핸들/소켓 추상화에 액세스할 수 없으므로 원본 MIT-MAGIC-COOKIE가 필요합니다..X 권한그리고 그는 새로운 Xorg 컨텍스트를 생성하기 위해 /tmp/X11/X0 파일/abstract-socket에 액세스해야 합니다.
Firejail 및 Linux 네임스페이스의 기본 아이디어는 이러한 리소스를 숨기고 새 Xorg 컨텍스트를 생성하지 못하도록 방지하는 것입니다.
이를 위해 Firejail은 Linux 네임스페이스를 사용하고 애플리케이션을 /tmp/*가 존재하지 않는 새 네임스페이스로 이동합니다. 또한 다음을 사용하여 애플리케이션을 위한 새로운 브리지 인터페이스를 제공합니다.--네트워크=따라서 응용 프로그램은 .Xauthority 파일을 볼 수 없으며 Xorg와 통신할 수 없습니다. 응용 프로그램은 브리지 인터페이스를 통해 통신하기 때문에 인터넷을 볼 수 있습니다/허용된다고 가정하지만 해당 보기는 br0 등의 방화벽에 의해 제한됩니다.
응용 프로그램 자체는 Xorg 소켓 포인터를 사용하여 공유 메모리를 사용하는 Xorg와 통신하며 포인터를 유지하는 한 무기한으로 통신할 수 있습니다.
그렇다면 Firejail 보안은 메모리에서 완전히 충돌하고 Xorg CONTEXT/포인터를 잃는 애플리케이션에 의존합니까? 하지만 해커가 애플리케이션에 세그폴트를 시도하고 해당 코드를 다시 작성하면서도 Xorg 컨텍스트를 계속 유지할 수 있습니까?그러나 이는 우리가 감수해야 하는 위험이며 아마도 다음과 같은 방법으로 피할 수 있습니다.의류/SELinux시스템 호출을 모니터링합니까?
하지만 우리는 왜 사용하지 않는가?명명된 파이프대신에? 명명된 파이프/.Xauthority를 생성하고수출 허가응용 프로그램을 시작합니다. 차단되므로 서버 측에서 현재 쿠키를 작성하고 응용 프로그램이 시작된 후 이를 변경하는 일부 프로그램을 실행합니다. 따라서 응용 프로그램 세그폴트가 발생하고 해커가 일반 사용자이거나 쿠키 제한이 없는 경우, 해커는 새 쿠키를 훔칠 희망이 전혀 없습니다. 특히 사용자를 지우거나 삭제하거나 모든 파일을 삭제하고 재실행을 시작하는 경우에는 더욱 그렇습니다. 각 응용 프로그램 .
Firejail은 이를 어떻게 다르게 수행합니까? 애플리케이션을 시작해야 하는 경우 .Xauthority 및 소켓 파일을 제공해야 합니다. 그러면 그는 무엇을 합니까? 애플리케이션을 새 NS로 이동합니까? 이동 시기를 어떻게 알 수 있습니까? 많은 애플리케이션이 .Xauthority를 여러 번 폴링하는데, Firejail은 이러한 리소스를 숨길 시기를 어떻게 알 수 있으며 정확히 어떻게 숨길까요?
답변1
Xorg 애플리케이션을 감옥에 넣는 목적은 @/tmp/X11/X0 및 /tmp/X11/X0에 액세스한 다음 MIT-MAGIC-COOKIE를 재사용하여 X 서버에 연결된 다른 애플리케이션을 훔치는 것을 방지하는 것입니다.
아니요? 예를 들어 읽으면이 가이드,
샌드박스는 일반 X11 서버를 Xpra 또는 Xepyr 서버로 대체합니다. 이는 X11 키로거와 스크린샷 유틸리티가 기본 X11 서버에 액세스하는 것을 방지합니다.
따라서 X 응용 프로그램을 감옥에 넣는 목적은 X 응용 프로그램이 주 서버에 접근하는 것을 완전히 차단하고 대신 프록시 서버에 접근하도록 허용하는 것입니다. 응용 프로그램이 프록시 서버를 사용하려고 시도하더라도 기본 서버에는 영향을 미치지 않습니다.
당신이 설명하는 특정 시나리오가 무엇인지는 잘 모르겠지만, MIT 쿠키를 사용하기 위한 초기 인증이 응용 프로그램 자체에서 수행되지 않은 경우에도 어떻게든 주 서버에 액세스할 수 있는 X 응용 프로그램은 이 서버에 있을 수 있습니다. 키로깅이나 다른 창에 액세스하는 것과 같은 것입니다. 이를 수행하기 위해 충돌할 필요는 없습니다. 따라서 처음에 애플리케이션을 승인한 다음 다시 승인되는 것을 방지하는 것은 도움이 되지 않습니다.
특정 방식으로 감옥에 갇힌 애플리케이션을 실행하는 목적이 프록시 X 서버에 액세스하도록 하는 것임을 놓쳤을 가능성이 있습니까?
편집하다
나는 감옥에 갇힌 응용 프로그램을 보호하기 위해 Firejail이 전통적인 xauth/.Xauthority 관행과 어떻게 다른지 이해하려고 노력하고 있습니다.
Firejail은 X 서버 프록시를 애플리케이션에 노출하고 애플리케이션이 기본 X 서버에 액세스하는 것을 방지합니다. 그게 다야. 전통적인 xauth 메커니즘은 응용 프로그램과 X 프록시 간이든 X 프록시와 기본 X 서버 간이든 정확히 동일합니다. (예,틀림없이X 에이전트가 메인 서버에 접근해야 하거나, 메인 X 서버와 X 에이전트를 모두 접근할 수 있는 프로그램이 있어야 합니다. 하지만 이 프로그램들은신뢰할 수 있는, 애플리케이션과 달리).
그런 다음 네임스페이스를 사용하여 쿠키가 누출되는 것을 방지하고 Xorg 소켓을 숨기는 추가 조치로 사용합니다.
아니요. 네임스페이스의 목적은 기본 X 서버 통신 끝점에 액세스할 수 없게 만드는 것입니다. 그것은 "그들은 존재하지 않는다"와 같습니다. 실제로는 아무것도 "숨기지" 않습니다("거기 있지만 볼 수 없습니다"). 수감된 앱은 더 이상 존재하지 않습니다. 마찬가지로 Docker 컨테이너는 네임스페이스를 사용하여 컨테이너의 애플리케이션이 완전히 다른 환경에서 실행되는 것처럼 가장할 수 있도록 합니다.
감옥에 갇힌 응용 프로그램이 기본 X 서버 통신 끝점을 볼 수 없도록 하는 것만으로도 충분하지만, 감옥에 갇힌 응용 프로그램이 기본 X 서버의 유효한 MIT 쿠키를 볼 이유가 없습니다.
명명된 파이프그것은 정말로 그것과 아무 관련이 없습니다. 충돌도 없었습니다. X 인증 메커니즘의 작동 방식에도 변경 사항이 없습니다.
답변2
그래서 저는 Xorg 메일링 리스트에 이메일을 보냈고 그들은 매우 도움이 되었습니다. 그래서 그것이 모든 것이 작동하는 방식입니다.
Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat Seat0 vt7 -novtswitch UNIX 도메인 소켓(debian에서 가져옴)을 제외하고 청취를 끄는 데 사용되는 명령입니다.
이로 인해/tmp/X11/X0 및 @/tmp/X11/X0 추상 소켓생성되고 있습니다.
Xorg는 이 파이프/소켓을 통해 쿠키를 받습니다(프로그램에서 사용).Gtk/Qt-->Xlib[.Xauthority]) XDM에서 제공한 내부 쿠키와 비교합니다. 일치하는 경우 Xorg는 내부 컨텍스트를 생성하고 해당 컨텍스트를 IP:Port(tcp/ip 연결의 경우) 또는 응용 프로그램 FD(소켓의 경우) [명명된 파이프 소켓/FD 생성]과 연결합니다.1.
기본적으로 /tmp/X11/X0에 쓰는 모든 응용 프로그램은 Xorg가 그 끝에 고유한 FD를 생성하게 합니다. 응용 프로그램이 종료되고 종료되면 FD는 Xorg에 의해 닫히지만 응용 프로그램이 삽입되면 Xorg FD/컨텍스트는 파괴되지 않으며 바이러스/사악한 응용 프로그램이 응용 프로그램을 속이고 Xorg와 계속 통신할 수 있습니다. Xorg는 XOpenDisplay/MIT-COOKIE 이후에 인증을 위해 IP:Port만 사용하기 때문에 응용 프로그램이 network/tcp를 사용하는 경우 더 쉽습니다. [쿠키는 Xorg에 대한 하나의 API 호출에만 사용됩니다.]
응용 프로그램이 원하는 경우 COOKIE를 메모리에 유지하여 해커가 COOKIE를 훔칠 수 있도록 할 수 있지만 이 인증 비트는 Xlib의 작업입니다. Firejail은 쿠키 도난으로부터 실제로 보호하지 않습니다. 그것이 하는 일은 Xvfb를 사용하여 애플리케이션 GUI를 렌더링한 다음 Xpra를 사용하여 픽스맵을 Xorg 서버로 보내는 것입니다. Xorg 서버는 클라이언트 Xpra와 서버 Xpra(Xpra 문서/readme에서 이에 대해 설명합니다)의 두 부분으로 나뉩니다. 서버는 pixmap만 볼 수 있고 신뢰할 수 있는 프록시/Xpra 서버/클라이언트/Burqa 보호의 API 호출은 볼 수 없기 때문에 안전합니다. 하지만 Xorg는 한심할 정도로 약하고 보안이 없기 때문에 강간범들은 여전히 방황하고 있습니다. :p
모든 것을 하나로 묶는 테이프가 너무 많아서 깔끔하고 효율적이지는 않습니다. 비록 논쟁의 여지가 있다고 생각합니다. Xorg는 일회성 쿠키 인증을 제외하면 보안이 0입니다. 다른 시대를 위해 설계되었으므로.. 지금까지 아무 작업도 수행하지 않았습니다. 모든 종류의 수상한 해킹 기술을 사용하고 어떤 이유로 C에 있는 Firejail을 사용하는 것보다 cgroup/resource-limit 및 네임스페이스를 적용하기 위해 bash 스크립트를 작성하는 것이 더 쉬울 것이라고 생각합니다. Xorg의 경우.. Xvfb를 읽고 감옥을 통해 Xorg에 데이터를 추출/전송해야 합니다.