Повышаем безопасность контейнеров Docker

[grossws]

Предположим, что сканирование выявило критические уязвимости в libxml2 и libxslt. Это buildtime-зависимости гема Nokogiri, который является XML- и JSON-парсером. С целью увеличения производительности этот гем использует написанные на Си расширения, требующие компиляции. Но после того как гем установлен, libxml2 и libxslt больше не нужны.

В современном nokogiri libxml2 забандлен, но до этого (сейчас только с --use-system-libraries) умеет линковаться с системной libxml2 и libxslt. И, естественно, использует их в рантайме, иначе нафига они сдались?

proof

gross@unterwelt [11:54:50] [~/experiments] 
-> % gem install nokogiri -v1.6.7.2 -- --use-system-libraries
Building native extensions with: '--use-system-libraries'
This could take a while...
Successfully installed nokogiri-1.6.7.2
Parsing documentation for nokogiri-1.6.7.2
Installing ri documentation for nokogiri-1.6.7.2
Done installing documentation for nokogiri after 4 seconds
1 gem installed
gross@unterwelt [11:55:12] [~/experiments] 
-> % ldd ~/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/ext/nokogiri/nokogiri.so
        linux-vdso.so.1 (0x00007fff385a1000)
        libruby.so.2.3 => /home/gross/.rvm/rubies/ruby-2.3.0/lib/libruby.so.2.3 (0x00007f16a44bc000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f16a4107000)
        libxslt.so.1 => /usr/lib/libxslt.so.1 (0x00007f16a3ec6000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f16a3caf000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f16a3a89000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f16a3785000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f16a357f000)
        libexslt.so.0 => /usr/lib/libexslt.so.0 (0x00007f16a3369000)
        libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f16a305a000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f16a2e46000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f16a2c29000)
        libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f16a2996000)
        libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f16a275c000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f16a23be000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x000055d2993e0000)

Если, конечно, nokogiri потом не использовать, то его runtime-зависимости можно и снести.

Всякие -dev/-devel пакеты в итоговом контейнере в почти любом случае не к чему (кроме контейнера для сборки такого барахла), а при сборке пакета требуются. Их отсутствие (и компилятора заодно) продакшн системе не мешает.

[Wolverine]

По умолчанию контейнеры Docker запускаются с привилегиями root, что может привести к серьезным проблемам в случае прорыва изоляции, так как запущенный под рутом скомпрометированный контейнер может получить root-доступ к основной системе.

USER rails

Расскажите пожалуйста каким образом это может произойти? Зашли мы в наш контейнер через docker exec и сидим из под root, что мы можем сделать деструктивного с хост-машиной?

[gekk0]

«В выпуске cистемы управления контейнерной виртуализацией Docker 1.12.6 устранена опасная уязвимость (CVE-2016-9962), позволяющая получить доступ к хост-системе из изолированного контейнера. Уязвимость вызвана недоработкой в runtime runC, который используется по умолчанию начиная с ветки Docker 1.11, и также применяется в некоторых других системах»
https://www.opennet.ru/opennews/art.shtml?num=45848

[Wolverine]

Спасибо. В целом получается, что лучше пользователя сменить, на случай вот таких багов.