윈도우 RDP로 접속 가능한 한글 XWINDOW Docker 이미지
(github.com/lancard)최신 Debian 13(Trixie) 기반 한글 XWINDOW (wayland) Docker 이미지를 만들어 공개합니다.
실제로 윈도우 쓰시는 분들이 많은데, 가끔가다 도커로 한글되는 리눅스 X윈도우 띄워서 작업하시고 싶을 때가 가끔 있으실거에요.
그래서!
윈도우 원격 데스크탑으로 접근 가능한 데비안 기반 한글 GUI 환경을 만들어보았습니다.
이 이미지에는 Visual Studio Code, Chromium, Vim, Git, Node.js + npm 등 개발 환경에 필요한 주요 툴이 기본 설치되어 있어, 바로 개발 환경으로 활용할 수 있습니다. (덕분에 덩치가 좀 큽니다)
주요 특징으로는,
- 윈도우 원격 데스크탑(RDP) 접속 가능
- 데이터 및 볼륨 유지: /home/(사용자명)을 Docker 볼륨으로 연결하면 데이터 지속 가능
주의사항으로는,
Docker에서 실행되므로 VSCode와 Chromium은 sandbox 모드 미사용됩니다. 보안 유의 부탁드리고요, 사운드 기능은 충돌과 버그가 많아 제외되었습니다. 제 생각으로는 대부분 음악은 윈도우 PC 에서 듣고 계실 것 같아서 제외하였습니다.
개발 환경을 빠르게 구축하고 싶은 한글 사용자에게 특히 유용한 이미지입니다.
소스는 https://github.com/lancard/x11-korean 있으니 참고하시고, 필요하신 기능 있다면 언제든 이슈나 PR 날려주세요!
내부의 vscode 에서 새 파일 생성은 되는데 기존 파일 수정은 안됩니다. chmod 777 로 기존 파일을 바꿔줘도. 권한이나 그룹 소유권 문제일 거 같은데 좀 더 이거저거 시도해보겠습니다.
set username
XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi
부분을
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # 기본 1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi
로 바꿔서 USER_ID 를 호스트머신의 계정 아이디와 동일하게 넣어주었습니다.
두가지의 OS가 혼합되는 것을 좋아하지 않아요. 어떤 사이드 이펙트가 있을지도 모르고요. 각각의 OS 는 샌드박스거나 물리서버 한개만 점유해야 한다고 생각합니다. 게다가 과거에 WSL이 동작이 이상했던 경험도 있고요.
제가 알고 있는 지식에서 말씀하시는 내용이 잘이해가 되지 않아서 혹시
wsl나 docker의 기본적인 논리 구조와 비슷하지 않나요?
제가 잘못 짚은 부분이 있을까요?
WSL2은 좀 비슷하다고 하실 수 있긴한데, WSL은 구조가 좀 다릅니다. 기본적으로 윈도우 커널위에서 돌아요. WSL2은 하이퍼바이저 위에서 도는게 맞긴합니다만, 격리 수준 조금 다르다고 생각합니다. 자동 마운트를 양쪽으로 하다보니 OS 가 서로의 파일시스템에 접속할 수 있어요. 그러다보니 원치 않는 결과가 생길 수 있죠. 예를들어 윈도우가 $RECYCLE.BIN 을 ext4 에 자동 생성한다거나, 한쪽 OS 가 해커한테 점령당한 상황이면 양쪽에 치명적이죠. 제가 만든건 원하면 아무것도 마운트하지 않아도 됩니다. 윈도우랑 연결안하고 혼자만 돌게 할 수 있습니다.
그리고 설치 속도도 영향이 있달까요... 그냥 제 이미지 방식은 맘에 안들면 docker 이미지를 밀어버리고 새로 하나 더 복사하면 됩니다. 업데이트 할 때도 그냥 이미지만 받으면 되는거죠. WSL2 네트워크쪽도 문제가 좀 있었던 걸로 기억합니다. 또한 리눅스 커널도 순수 리눅스 커널이 아니고 MS 가 커스터마이징한걸로 알아요.
순수 리눅스를 지향하는 (그니까 서로 격리되는 걸 원하는) 저랑은 좀 안맞습니다.
단점만 열거하긴 했지만 사실 개인 취향차이도 좀 있다보니 원하시는 걸 선택하시면 되겠습니다.
그리고 docker 자체가 거의 리눅스 only 기도 하고, nas 위에 docker 를 돌린다거나, 대/소문자 구분이라거나 docker 로 하는게 이익이 많아서 만든 것이라고 보시면 되겠습니다.
privileged mode 인 경우 sandbox 에서 돌도록 수정했습니다. privileged mode 인 경우 로컬리소스(C드라이브 등)을 연결할 수 있습니다. 연결은 $HOME/thinclient_drives에 마운트됩니다.
제가 계속 이미지를 변경하고 있어서 중간 이미지라 그러실 수도 있습니다.
일단 바탕화면 vscode 아이콘이 명령이 /usr/bin/code %F 인지 확인해보시고요,
/usr/bin/code 파일 열어서 끝에서 두번째 줄이
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"
로 되어있는지 확인해보세요.
최근 도커 공부를 하는 사람입니다. trivy 로 이 이미지의 취약점을 검사해봤는데, 1053개의 취약점이 나왔습니다. 다 중요한거 같지는 않고 그냥 온갖 것들 다 잡아내는 것 같은데, 실무적으로 이미지의 보안성은 어떻게 확인하고 달성하는지 혹시 조언 부탁드려도 될까요
사실 취약점 제거 방법은 너무 많아서 정답이 없습니다만
저같은 경우 최대한 안정화된 최신버전 사용하고 github action 사용 시에는 security bot을 최대한 켜둡니다. 사실 이번 xwindow 이미지는 보시면 아시겠지만 프로그래밍한 부분이 없어서 설치된 프로그램들의 자체 기본 취약점만 있을거에요.
sandbox 모드가 적용되지 않은게 왜 보안 유의사항인가 궁금했습니다.
도커는 내부 프로세스에 샌드박스 기능을 제공하지 않는다는건가요? 그래서 어쩔 수 없이 루트로 실행될 수밖에 없고, 비록 도커로 격리된 환경이라 하더라도 호스트와 매핑된 볼륨에는 악성코드가 침투될수도 있는 위험을 의미한거에요? 아니면 도커 내부 파일시스템에 사용자가 생성한 파일이 안전하지 않을 수 있다는걸까요?
제가 알기론 윈도우든 리눅스든 크롬은 샌드박스 모드로 돕니다. 그니까... 혹시나 javascript 등으로 exploit 만들어서 취약점 공격을 해도 실제 OS 에는 영향을 미치지 않는거죠.
근데 컨테이너모드에서는 priviliged 모드를 켜야만 아마 그 기능을 켤 수 있을겁니다.
물론 해당 모드를 켜라고 안내할 수도 있긴합니다만, 컨테이너 자체가 샌드박스라고 저는 생각했어요. 손쉽게 켰다가 끄는 윈도우 같은 느낌이라고 해야 할까요...
그래서 크로미움과 일렉트론 기반 vscode 는 sandbox가 아닌 모드에서 돌게 해둔 것입니다.
어디까지나 크로미움과 vscode 에 취약점이 있고, 해당 공격자가 그걸 이용해서 exploit 을 만들 수 있다고 가정하면 위험할 수 있다는 뜻입니다.