Comments 4
Предположим, что сканирование выявило критические уязвимости в 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 пакеты в итоговом контейнере в почти любом случае не к чему (кроме контейнера для сборки такого барахла), а при сборке пакета требуются. Их отсутствие (и компилятора заодно) продакшн системе не мешает.

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

USER rails


Расскажите пожалуйста каким образом это может произойти? Зашли мы в наш контейнер через docker exec и сидим из под root, что мы можем сделать деструктивного с хост-машиной?
«В выпуске cистемы управления контейнерной виртуализацией Docker 1.12.6 устранена опасная уязвимость (CVE-2016-9962), позволяющая получить доступ к хост-системе из изолированного контейнера. Уязвимость вызвана недоработкой в runtime runC, который используется по умолчанию начиная с ветки Docker 1.11, и также применяется в некоторых других системах»
https://www.opennet.ru/opennews/art.shtml?num=45848
Спасибо. В целом получается, что лучше пользователя сменить, на случай вот таких багов.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

22 March 2008

Location

Россия

Employees

31–50 employees

Registered

15 November 2012