권한이없는 컨테이너의 장점과 단점은 무엇입니까?


답변:


14

권한없는 컨테이너를 실행하는 것이 프로덕션 환경에서 컨테이너를 실행하는 가장 안전한 방법입니다. 컨테이너는 보안에 관해 나쁜 평판을 얻습니다. 그 이유 중 하나는 일부 사용자가 사용자가 컨테이너에서 루트를 얻는 경우 호스트에서도 루트를 얻을 가능성이 있다는 것을 발견했기 때문입니다. 기본적으로 권한이없는 컨테이너가하는 일은 호스트에서 사용자 ID를 마스킹하는 것입니다. 권한이없는 컨테이너를 사용하면 루트가 아닌 사용자는 컨테이너를 작성할 수 있으며 컨테이너에 루트로 표시하고 컨테이너에 표시하지만 호스트와 같이 사용자 ID 10000으로 표시됩니다 (사용자 ID를 맵핑 한대로). 필자는 최근 LXC 에 관한 Stephane Graber의 블로그 시리즈 (LXC의 훌륭한 사고 / 리드 개발자 중 하나이며 반드시 따라야 할 사람)에 기반한 블로그 게시물을 작성했습니다 . 다시 한 번, 매우 훌륭합니다.

내 블로그에서 :

컨테이너에서 :

lxc-attach -n ubuntu-unprived
root@ubuntu-unprived:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 04:48 ?        00:00:00 /sbin/init
root       157     1  0 04:48 ?        00:00:00 upstart-udev-bridge --daemon
root       189     1  0 04:48 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
root       244     1  0 04:48 ?        00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid
syslog     290     1  0 04:48 ?        00:00:00 rsyslogd
root       343     1  0 04:48 tty4     00:00:00 /sbin/getty -8 38400 tty4
root       345     1  0 04:48 tty2     00:00:00 /sbin/getty -8 38400 tty2
root       346     1  0 04:48 tty3     00:00:00 /sbin/getty -8 38400 tty3
root       359     1  0 04:48 ?        00:00:00 cron
root       386     1  0 04:48 console  00:00:00 /sbin/getty -8 38400 console
root       389     1  0 04:48 tty1     00:00:00 /sbin/getty -8 38400 tty1
root       408     1  0 04:48 ?        00:00:00 upstart-socket-bridge --daemon
root       409     1  0 04:48 ?        00:00:00 upstart-file-bridge --daemon
root       431     0  0 05:06 ?        00:00:00 /bin/bash
root       434   431  0 05:06 ?        00:00:00 ps -ef

호스트에서 :

lxc-info -Ssip --name ubuntu-unprived
State:          RUNNING
PID:            3104
IP:             10.1.0.107
CPU use:        2.27 seconds
BlkIO use:      680.00 KiB
Memory use:     7.24 MiB
Link:           vethJ1Y7TG
TX bytes:      7.30 KiB
RX bytes:      46.21 KiB
Total bytes:   53.51 KiB

ps -ef | grep 3104
100000    3104  3067  0 Nov11 ?        00:00:00 /sbin/init
100000    3330  3104  0 Nov11 ?        00:00:00 upstart-udev-bridge --daemon
100000    3362  3104  0 Nov11 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
100000    3417  3104  0 Nov11 ?        00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
100102    3463  3104  0 Nov11 ?        00:00:00 rsyslogd
100000    3516  3104  0 Nov11 pts/8    00:00:00 /sbin/getty -8 38400 tty4
100000    3518  3104  0 Nov11 pts/6    00:00:00 /sbin/getty -8 38400 tty2
100000    3519  3104  0 Nov11 pts/7    00:00:00 /sbin/getty -8 38400 tty3
100000    3532  3104  0 Nov11 ?        00:00:00 cron
100000    3559  3104  0 Nov11 pts/9    00:00:00 /sbin/getty -8 38400 console
100000    3562  3104  0 Nov11 pts/5    00:00:00 /sbin/getty -8 38400 tty1
100000    3581  3104  0 Nov11 ?        00:00:00 upstart-socket-bridge --daemon
100000    3582  3104  0 Nov11 ?        00:00:00 upstart-file-bridge --daemon
lxc       3780  1518  0 00:10 pts/4    00:00:00 grep --color=auto 3104

보시다시피 프로세스는 컨테이너 내부에서 루트로 실행되고 있지만 루트는 아니지만 호스트에서 100000으로 나타납니다.

요약하자면 다음과 같습니다. 이점-보안 강화 및 보안 격리 강화. 단점-초보 사용자가 아닌 처음부터 머리를 감쌀 수있는 약간 혼란 스럽습니다.


3
따라서 올바르게 이해하면 컨테이너 자체가 100 % 안전하지 않습니다. 어떤 컨테이너를 사용하든 짐승이 도망 갈 가능성이 있습니다. 그리고 컨테이너 유형이 중요해질 때만 여기 있습니다. 특권 컨테이너의 경우, 짐승은 루트에서 야생으로 실행되어 루트킷을 심고 귀중한 SSL 키를 munching합니다. 권한이없는 경우 컨테이너를 만든 사용자 계정으로 만 제한됩니다. 그의 SSH 키 등을 도용하는 것이 더 안전합니까? 네 개의 중첩 상자 그림으로 설명 할 수 있습니까?
anatoly techtonik

2
요컨대, 컨테이너 자체는 즉시 사용하기에 안전하지 않습니다. 다른 Linux 환경과 마찬가지로 LXC 환경을 취급하십시오. 리눅스 박스를 크게 열어 두지 않겠습니까?! 예, 컨테이너는 사용자 계정이 매핑 된 것으로 만 제한됩니다. 권한없는 Conatiners에 대한 Graber의 게시물을 확인하십시오. 모든 컨테이너가 동일한 커널을 공유하기 때문에 가장 큰 문제는 커널과 syscall을 악용 할 수 있다고 생각합니다. clinux 및 selinux, apparmor 및 seccomp 등과 같은 다른 응용 프로그램을 통해 보안을 강화하는 방법에는 여러 가지가 있습니다.
geekbass


따라서 컨테이너를 실행할 별도의 제한된 사용자를 작성하십시오. 공정한 것 같습니다. 나는 이것을 대답으로 받아들입니다. 감사.
anatoly techtonik

4

테스트, 샌드 박싱 및 캡슐화에 매우 유용한 도구입니다. 민감한 개인 파일에 액세스 할 수없는 웹 서버를 자체 작업 환경에서 안전하게 잠그기를 원하십니까? 용기를 사용하십시오. 다른 응용 프로그램과 호환되지 않는 이전 버전의 라이브러리가 필요한 응용 프로그램과 특정 구성 파일이 있습니까? 또한 용기. 기본적으로 chroot가 올바르게 수행되었습니다. 이를 통해 서비스를 충분히 별도로 유지 관리 할 수 ​​있으므로 각 서비스를 훨씬 쉽게 유지 관리 할 수 ​​있으며 기존 시스템을 방해하지 않고 다른 시스템으로 이동하거나 복사 할 수 있습니다.

단점은 거의 모든 것이 컨테이너의 로컬 네임 스페이스를 기억해야한다는 것입니다. 현재 위치를 알고 있어야하며 컨테이너 간 통신이 쉽지 않습니다. 모듈화가 필요하지만 가상 머신의 오버 헤드를 원하지 않는 경우가 좋으며 컨테이너에 보관하는 것은 실제로 관련이 없습니다.

"일반적인"사용자의 경우 컨테이너를 사용하여 두 사람이 단일 시스템을 사용하면서 완전히 다른 시스템에있는 것처럼 유지할 수 있습니다. 예를 들어 룸메이트.


3
컨테이너가 무엇인지에 대한 인간의 설명은 훌륭하지만 여전히 권한이있는 컨테이너와 권한이없는 컨테이너의 차이점을 설명하지는 않습니다.
anatoly techtonik

1

공유 커널을 사용하면 적의 요구 사항이 어떤 방식 으로든 (또는 오히려 공격 표면을 제한하는 데 도움이 됨) 요구에도 불구하고 권한이없는 컨테이너는 여전히 호스트 루트를 얻는 직선 해킹에서 완전히 격리되지는 않습니다. .

이런 이유로 약간 잘못된 가정 / 청구입니다. 인터넷을 통해 많은 사용자의 기술 적성 수준은 여전히 ​​기술적으로 불가능한 여러 가지 방법으로 inet 서비스를 계속 실행할 수 있습니다. :)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.