The following pull request was submitted through Github. It can be accessed and reviewed at: https://github.com/lxc/linuxcontainers.org/pull/152
This e-mail was sent by the LXC bot, direct replies will not reach the author unless they happen to be subscribed to this list. === Description (from pull-request) ===
From fa0a5b0b10f11e60ffd14f65c99b246303b31130 Mon Sep 17 00:00:00 2001 From: Sungbae Yoo <sungbae....@samsung.com> Date: Mon, 29 Feb 2016 11:44:34 +0900 Subject: [PATCH] Update Korean security page for adding some security details Update for commit d796145 Signed-off-by: Sungbae Yoo <sungbae....@samsung.com> --- content/lxc/security.ko.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/content/lxc/security.ko.md b/content/lxc/security.ko.md index 80cda71..b45875f 100644 --- a/content/lxc/security.ko.md +++ b/content/lxc/security.ko.md @@ -4,7 +4,7 @@ LXC 컨테이너는 두가지로 나눌 수 있습니다. - 특권 컨테이너 - 비특권 컨테이너 -전자는 이전 형식의 컨테이너라고 할 수 있습니다. 안전하지 않으므로, 비특권 컨테이너가 가능하지 않는 환경이나 컨테이너의 유저가 root에 접근해도 상관없을 때 사용하여야 합니다. +전자는 이전 형식의 컨테이너라고 할 수 있습니다. 안전하지 않으므로, 비특권 컨테이너가 가능하지 않는 환경이나 컨테이너의 사용자가 root에 접근해도 상관없을 때 사용하여야 합니다. 후자는 LXC 1.0 (2014년 2월)에서 도입되었으며, 최신 커널 (3.13보다 높은)이 요구됩니다. 이 컨테이너의 장점은 root 권한을 이용한 공격에 대해 안전하므로, 커널의 보안 문제가 없는 한 컨테이너는 안전하다는 것입니다. @@ -42,6 +42,31 @@ LXC는 커널 보안 문제를 다룰 수 있는 하나의 추가 보안 레이 LXC 개발진은 기꺼이 이러한 보안 문제를 추적하는 것을 도와줄 것입니다. 그리고 가능한한 빨리 해결하기 위해 리눅스 커널 커뮤니티에 연락을 취할 것입니다. +# 잠재적 DoS 공격 +LXC는 기본적으로 DoS 공격을 막지는 않습니다. 여러개의 신뢰할 수 없는 컨테이너들을 실핼할 때, 또는 신뢰할 수 없는 사용자들에게 컨테이너들을 실행할 수 있게 허용할 때, 아래 사항들을 염두에 두고 설정 사항들을 업데이트해 나가야 합니다. + +## Cgroup 제한 +LXC는 자신의 부모로부터 cgroup 제한들을 상속받습니다. Linux 배포판이라면 제한이 설정되어 있지 않을 것입니다. +그 결과, 컨테이너 내의 사용자는 fork 폭탄 방법으로 꽤 쉽게 host에게 DoS 공격을 가할 수 있습니다. 또한 모든 시스템의 메모리를 사용하거나 커널이 메모리를 모두 소진할 떄까지 네트워크 인터페이스를 생성할 수 있습니다. + +이러한 문제들은 적절한 lxc.cgroup 항목(memory, cpu, pids) 설정을 통해 어느정도 해결할 수 있습니다. 또는 부모 사용자가 로그인 시간에 적절히 설정된 cgroup에 위치할 수 있도록 하여, 해결할 수도 있습니다. + +## 사용자 제한 (ulimit) +cgroup 처럼, 부모의 제한은 비특권 컨테이너로 상속되기 때문에, 부모보다 높은 ulimit 값은 설정할 수 없습니다. + +다만 염두에 두어야할 부분이 있는데, 네임스페이스가 제공하는 ulimit은 커널 관점의 uid로 묶여있다는 점입니다. 즉, 전역적인 커널 uid이며, 사용자 네임스페이스 안에서의 uid가 아닙니다. + +만약 서로 같은 커널 uid를 사용하는 id 매핑을 가지고 있는 두개의 컨테이너가 있다면, 그들은 서로 제한을 공유하게 되는 것입니다. +이는 어떤 컨테이너 내의 사용자가 다른 컨테이너의 동일한 사용자에게 DoS 공격을 가할 수 있음을 의미합니다. + +이를 막기 위해서, 신뢰할 수 없는 사용자나 컨테이너는 id 매핑을 완전히 분리할 필요가 있습니다. (이상적으로는 65536개의 uid와 gid 각각에 대하여) + +## 네트워크 브리지 공유 +LXC는 컨테이너를 위해 L2 연결을 설정합니다. 또한 편의를 위해 시스템에 1개의 기본 브리지를 제공합니다. + +브리지에 연결된 컨테이너는 그들이 원하는 어떠한 L2 트래픽이라도 전송가능합니다. 따라서 브리지에 MAC/IP 스푸핑 공격을 하는 것이 가능합니다. +신뢰할 수 없는 컨테이너들을 실핼할 때, 또는 신뢰할 수 없는 사용자들에게 컨테이너들을 실행할 수 있게 허용할 때, 이상적으로는 사용자 하나당 또는 컨테이너 그룹 하나당 하나의 브리지를 사용해야 합니다. 그리고 /etc/lxc/lxc-usernet에 그들이 할당한 브리지만 사용할 수 있도록 설정하여야 합니다. + # 보안 문제 보고하기 보안 문제를 가능한 빨리 모든 리눅스 배포판에서 고치길 원한다면, 아래 방법을 통해 해당 문제를 보내주시면 됩니다.
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
