?
本文檔使用 php中文網(wǎng)手冊 發(fā)布
Linux名稱空間為正在運行的進程提供了隔離，限制了它們對系統(tǒng)資源的訪問，而不需要運行進程意識到這些限制。有關(guān)linux命名空間的更多信息，請參見Linux命名空間；
防止容器內(nèi)權(quán)限升級攻擊的最佳方法是將容器的應(yīng)用程序配置為以非特權(quán)用戶的身份運行。對于進程必須以root容器中的用戶，您可以在Docker主機上將該用戶重新映射到特權(quán)較低的用戶。映射的用戶被分配了一個UID范圍，這些UID在命名空間中作為普通UID在0到65536之間運行，但是在主機本身上沒有特權(quán)。
關(guān)于重映射和從屬用戶和組ID
重映射本身由兩個文件處理：/etc/subuid和/etc/subgid每個文件的工作方式相同，但一個文件涉及用戶ID范圍，另一個文件涉及組ID范圍。中的下列條目/etc/subuid*
testuser:231072:65536
這意味著testuser的從屬用戶ID范圍為230172接下來的65536個整數(shù)按順序排列。UID231072映射到容器內(nèi)的命名空間%28中，在本例中%29映射為UID。0%28root29%。UID231073映射為1等等。如果某個進程試圖在命名空間之外提升權(quán)限，則該進程在主機上作為一個非特權(quán)的高數(shù)字uid運行，它甚至不映射到真正的用戶。這意味著進程在主機系統(tǒng)上完全沒有特權(quán)。
多重范圍 屬性中的同一用戶或組添加多個非重疊映射，從而為給定用戶或組分配多個從屬范圍。
/etc/subuid或/etc/subgid檔案。在這種情況下，Docker只使用六映射，這與內(nèi)核僅限制在/proc/self/uid_map和/proc/self/gid_map...
當您將Docker配置為使用userns-remap特性，您可以選擇指定現(xiàn)有用戶和/或組，也可以指定default.如果您指定default，用戶和組dockremap被創(chuàng)建并用于此目的。
警告某些發(fā)行版(如rhl和CentOS 7.3)不會自動將新組添加到
/etc/subuid和/etc/subgid檔案。在本例中，您負責編輯這些文件并分配不重疊的范圍。此步驟將在先決條件...
非常重要的是，范圍不能重疊，這樣進程就不能在不同的命名空間中獲得訪問權(quán)限。在大多數(shù)Linux發(fā)行版上，系統(tǒng)實用程序在添加或刪除用戶時為您管理范圍。
這種重新映射對容器是透明的，但是在容器需要訪問Docker主機上的資源的情況下，例如綁定安裝到系統(tǒng)用戶無法寫入的文件系統(tǒng)的區(qū)域時，會引入一些配置復雜性。從安全的角度來看，最好避免這些情況。
先決條件
從屬UID和GID范圍必須與現(xiàn)有用戶相關(guān)聯(lián)，即使關(guān)聯(lián)是實現(xiàn)細節(jié)。用戶將擁有下面的命名空間存儲目錄。
/var/lib/docker/如果您不想使用現(xiàn)有用戶，Docker可以為您創(chuàng)建一個用戶并使用它。如果要使用現(xiàn)有的用戶名或用戶ID，則必須已經(jīng)存在。通常，這意味著相關(guān)條目需要在/etc/password和/etc/group但是，如果您使用的是不同的身份驗證后端，則此要求可能會有不同的轉(zhuǎn)換。 若要驗證這一點，請使用id指揮： $id testuser uid=1001%28 testuser%29 gid=1001%28 testuser%29組=1001%28 testuser%29
主機上處理名稱空間重映射的方式是使用兩個文件，
/etc/subuid和/etc/subgid這些文件通常在添加或刪除用戶或組時自動管理，但在少數(shù)發(fā)行版(如RHEL和CentOS 7.3)上，可能需要手動管理這些文件。
每個文件包含三個字段：用戶的用戶名或ID，后面是起始UID或GID%28，在命名空間%29中被視為UID或GID 0，以及用戶可用的UID或GID的最大值。例如，考慮到以下條目：
測試用戶：231072：65536
這意味著由testuser將由主機UID擁有。231072%28，它看起來像UID0在命名空間%29到296608%28231072+65536%29中。這些范圍不應(yīng)重疊，以確保命名空間進程不能訪問對方的命名空間。
添加用戶后，請檢查/etc/subuid和/etc/subgid若要查看用戶在每個項目中是否有一個條目，請執(zhí)行以下操作。如果不是，您需要添加它，小心避免重疊。
如果您想使用dockremap由Docker自動創(chuàng)建的用戶，您需要檢查dockremap這些文件中的條目后配置和重新啟動Docker。
如果Docker主機上有任何位置需要非特權(quán)用戶寫入，則相應(yīng)地調(diào)整這些位置的權(quán)限。如果要使用
dockremap由Docker自動創(chuàng)建的用戶，但在配置和重新啟動Docker之前，您將無法修改權(quán)限。
使能
userns-remap將有效地屏蔽現(xiàn)有圖像和容器層，以及內(nèi)部的其他Docker對象。/var/lib/docker/這是因為Docker需要調(diào)整這些資源的所有權(quán)，并將它們實際存儲在/var/lib/docker/最好是在新的Docker安裝上啟用此功能，而不是在現(xiàn)有的安裝上啟用此功能。
如果您禁用userns-remap您將不會看到在啟用時創(chuàng)建的任何資源。
檢查局限性在用戶名稱空間上，以確保您的用例是可能的。啟用userns-在守護進程上重新映射你可以開始
dockerd帶著--userns-remap標記或按照此過程使用daemon.json配置文件。大daemon.json推薦方法。如果使用此標志，請使用以下命令作為模型：$ dockerd --userns-remap="testuser:testuser"
編輯
/etc/docker/daemon.json假設(shè)文件以前是空的，下面的條目將啟用userns-remap使用用戶和組調(diào)用testuser.您可以按ID或名稱對用戶和組進行尋址。如果組名或ID與用戶名或ID不同，則只需要指定它。如果同時提供用戶名和組名或ID，請用冒號%28分隔它們:%29字符。假設(shè)UID和GID為testuser是1001*
- `testuser`- `testuser:testuser`- `1001`- `1001:1001`- `testuser:1001`- `1001:testuser`
{“userns-remap”：“testuser”}
注*使用dockremap用戶和讓Docker為您創(chuàng)建它，將值設(shè)置為default而不是testuser...
保存文件并重新啟動Docker。
如果您使用的是
dockremap用戶，驗證Docker使用id命令。 $id dockremap uid=112%28 dockremap%29 gid=116%28 dockremap%29組=116%28 dockremap%29 驗證條目是否已添加到/etc/subuid和/etc/subgid* $grep dockremap/etc/subuid dockremap：296608：65536$grep dockremap/etc/subgid dockremap：296608：65536 如果這些條目不存在，請將文件編輯為root用戶并分配一個起始UID和GID，這是分配最多的UID加上偏移量%28在本例中，6553629%。小心不要讓范圍內(nèi)有任何重疊。
控件驗證以前的圖像不可用。
docker image ls命令。輸出應(yīng)該是空的。
從
hello-world圖像。 $docker運行Hello-world
驗證名稱空間目錄是否存在于
/var/lib/docker/命名為名稱空間用戶的UID和GID，由該UID和GID擁有，而不是組或世界可讀的。一些子目錄仍然屬于root并擁有不同的權(quán)限。
$sudo ls-ld/var/lib/docker/231072.231072/drwx。11 231072 231072 11 6月21日上午21：19/var/lib/docker/231072.231072/$sudo ls-l/var/lib/docker/231072.231072/共計14 drwx。5 231072 231072 5 6月21日6月21日上午21：19。3 231072 231072 3 6月21日上午21：21集裝箱。3根根3 6月21日21：19圖像drwxr-x-3根根3 6月21日21：19網(wǎng)絡(luò)drwx。4根根4 6月21日21：19插件drwx。2根根2，6月21日上午21：19。2 231072 231072 2 6月21日上午21：21。2根根2 6月21日21：19信任drwx。2 231072 231072 3 6月21日21：19卷
您的目錄清單可能有一些不同，特別是如果您使用的容器存儲驅(qū)動程序與aufs...
由重新映射的用戶擁有的目錄將被使用，而不是直接位于下面的相同目錄。/var/lib/docker/和未使用的版本%28，如/var/lib/docker/tmp/在這里的示例中，%29可以刪除。碼頭工人不會在userns-remap已經(jīng)啟用。
禁用容器的命名空間重映射
如果在守護進程上啟用用戶名稱空間，默認情況下，所有容器都是以啟用的用戶命名空間啟動的。在某些情況下，例如特權(quán)容器，您可能需要禁用特定容器的用戶命名空間。見用戶命名空間已知限制其中一些限制。
若要禁用特定容器的用戶命名空間，請?zhí)砑?code>--userns=host標志到docker create，，，docker run，或docker exec命令。
用戶命名空間已知限制
以下標準Docker功能與啟用用戶命名空間的Docker守護進程不兼容：
與主機%28共享PID或網(wǎng)絡(luò)命名空間
--pid=host或--network=host29%。
阿
--read-only容器文件系統(tǒng)。這是Linux內(nèi)核的限制，禁止在用戶命名空間內(nèi)重新安裝帶有修改標志的已安裝的文件系統(tǒng)。
外部%28卷或存儲%29驅(qū)動程序，這些驅(qū)動程序不知道或無法使用守護進程用戶映射。
使用
--privileged模式標志打開docker run也沒有指定--userns=host...
用戶名稱空間是一種高級特性，需要與其他功能進行協(xié)調(diào)。例如，如果從主機掛載卷，則必須預(yù)先安排文件所有權(quán)，需要對卷內(nèi)容進行讀或?qū)懺L問。
雖然用戶命名空間容器進程中的根用戶擁有容器內(nèi)超級用戶的許多預(yù)期權(quán)限，但Linux內(nèi)核基于內(nèi)部知識施加限制，即這是一個用戶命名空間進程。一個值得注意的限制是無法使用mknod命令。對象運行時，將拒絕在容器內(nèi)創(chuàng)建設(shè)備的權(quán)限。root用戶。
保安，，，命名空間
? 2017 Docker, Inc.
根據(jù)ApacheLicense，版本2.0獲得許可。
Docker和Docker標志是Docker公司在美國和/或其他國家的商標或注冊商標。
Docker，Inc.和其他各方也可以在這里使用的其他術(shù)語中擁有商標權(quán)。