The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

11% актуальных образов в репозиториях Docker содержат опасные уязвимости

15.03.2017 12:51

Проанализировав состав свежих образов, представленных в официальных репозиториях Docker, исследователи обнаружили, что в 11% из них присутствуют неисправленные опасные уязвимости, а в 13% уязвимости средней степени опасности. Для проверки использовалась утилита vuls, оценивающая версии установленных пакетов на наличие известных уязвимостей. Для сравнения, похожее исследование, проведённое два года назад среди официальных образов, помеченных как самые свежие (выставлен тег "latest"), показало наличие опасных уязвимостей в 23% образов и уязвимостей средней опасности в 24%.

Меньше всего уязвимостей было выявлено в образах, построенных на пакетной базе Debian (8.33%), а больше всего опасных уязвимостей было найдено в образах на базе Ubuntu (26.67%), при том, что на базе Ubuntu построено 16% из рассмотренных образов Docker, а на базе Debian - 79%. Наиболее часто встречающейся проблемой названа уязвимость CVE-2016-8610, которую можно использовать для инициирования отказа в обслуживании сервера через наводнение специально оформленными пакетами. Из опасных уязвиомостей лидером стали CVE-2016-4658 и CVE-2016-1252 в libxml2 и apt, которые встречаются в 5% рассмотренных образов.



  1. Главная ссылка к новости (https://www.federacy.com/docke...)
  2. OpenNews: В Docker 1.12.6 устранена уязвимость, позволяющая выбраться из контейнера
  3. OpenNews: Треть образов контейнеров в Docker Hub содержит опасные уязвимости
  4. OpenNews: Обновление Docker 1.3.2 с устранением критических уязвимостей
  5. OpenNews: Выявлена уязвимость, позволяющая выйти за пределы контейнеров Docker
  6. OpenNews: Раскрыта информация об уязвимости, позволяющей обойти авторизацию на Docker Hub
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46192-docker
Ключевые слова: docker
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (77) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, freehck (ok), 13:27, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Вот тут бы всяким поклонникам snap-ов и им подобных решений задуматься, но...
     
     
  • 2.5, Аноним (-), 13:39, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Не задумаются, ибо есть +100500 более серьёзных проблем, которые доскер/аппимаге/снап - как-то решили.
    Например: Никто не променяет возможность переползания сервера БД с одной машины на более быструю на отсутствие дубликаций библиотек.
    Ещё, такие универсальные средства распространения приложений действительно решают проблему распространения приложений. Собирать 100500 пакетов только для линукса - это не очень удобно, кстати, наш Дженкинс делает это в доскере. Угадайте почему....
     
     
  • 3.13, Аноним (-), 14:00, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    потому что вы поклонники Hype Drive Development
    https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22?gi=cca584186e41
     
     
  • 4.15, Аноним (-), 14:06, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Эти умные слова не к месту немного. Особенно в моём случае. Несколько лет назад, когда не было докеров/аппимагов/снапов, в них была такая же необходимость, как и сегодня. И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой. И да, тащить openvz и lxc за собой она не должна.
    С появлением доскера я вздохнул с облегчением.
     
     
  • 5.19, Moomintroll (ok), 14:32, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > … тащить openvz и lxc за собой она не должна. С появлением доскера я вздохнул с облегчением.

    Странная логика. Т.е. openvz или lxc — это оверхед, а докер - нормалёк?...

     
     
  • 6.23, Аноним (-), 14:53, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    там и докера не было. В те времена.
     
  • 5.22, anonimus (?), 14:38, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прямо таки целая неделя? И на каждый деплой? Или все таки один раз сделал и работает?
     
     
  • 6.24, Аноним (-), 14:55, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    один раз написал скрипт для сборки. Типа сегодняшнего Dockerfile, но без докера.

     
  • 5.29, Аноним (-), 15:27, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой.

    А пакетные менеджеры тогда ещё не изобрели?

     
     
  • 6.32, username (??), 15:34, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой.
    > А пакетные менеджеры тогда ещё не изобрели?

    Как бы, разные вещи, пакетник суть просто распаковщик.

     
  • 6.38, Аноним (-), 15:58, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> переносимой.

    Именно переносимой!

     
     
  • 7.39, username (??), 16:01, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Счас тебе скажут что собрать десяток пакетов под все сборки линукса не проблема, и ты просто не осилил. Как не осилил и сопровождение по зависимостям и прочим изменениям по типу моча вголову дистроклепателям.  
     
     
  • 8.43, Аноним (-), 16:36, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точно ... текст свёрнут, показать
     
  • 8.74, рлрлро (?), 20:36, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    просто кто-то не осилил OBS ... текст свёрнут, показать
     
  • 5.30, username (??), 15:29, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Плюсую, делал тоже самое, писал самопальные обвязки(что суть была, докер) над lxc и сквашем.
    Собственно все разговоры вокруг "о боже не юникс вей зависимости обновление" они как бы лет 5+ как летают вокруг таких тем. Теперь вот и докер под нож попал.
    Ребята, вам никто не мешает работать так как вам удобно, не мешайте и нам.

    По сабжу:
    1. Там на докерхабе гребаная свалка. Понимайте это или умрите.
    2. Тестировать стоит только звезданутые(официальные) образы, ибо от них только и откалываются при работе нормальные пацаны, остальное содержимое хаба просто помёт нечистоплотных девопсов.
    3. Этот кипиш всего лишь результат временного отсутствия автопроверки на уязвимости на хабе, тулзов достаточно, операция рутинная.  Пока это все на плечах конечных пользователей.

     
     
  • 6.34, анонимус вульгарис (?), 15:44, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > 2. Тестировать стоит только звезданутые(официальные) образы, ибо от них только и откалываются
    > при работе нормальные пацаны, остальное содержимое хаба просто помёт нечистоплотных девопсов.

    Разуваем глаза и читаем:

    > Проанализировав состав свежих образов, представленных в _официальных_ репозиториях Docker, исследователи обнаружили

    Если б тестировали всё подряд, результат был бы порядка 99%. На всякий случай, для тех кто не в курсе: чтобы получить статус официального образа, надо его обновлять не реже раза в неделю. И даже несмотря на это официальщики так обос#ались.

     
     
  • 7.37, username (??), 15:52, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хз, я откалываюсь от aws docker image и делаю апдейт+установку барахла на каждой мажорной сборке приложения. Тулзы еще ни разу не бибикали в CI процессе на уязвимости.
    У них список уязвимых реп есть?
     
  • 6.63, тигар (ok), 08:58, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > нечистоплотных девопсов.

    а бывают другие?

     
  • 5.55, vitvegl (?), 21:54, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Странно, потому как хоть Docker и смен backend на свой, проблемы связанные с ядром решить нельзя, хотя бывает необходимость в этом и не часто
     
  • 5.57, Михрютка (ok), 23:20, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    я вот хз как у вас поворачивается язык называть контейнеры переносимыми. понятно, что несколько лет назад гиперов не было.
     
  • 3.18, Аноним (-), 14:31, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >наш Дженкинс делает это в доскере. Угадайте почему....

    Что то мне страшно, может стоит заменить дженкинс на красивый gitlab-ci-multi-runner
    ну или тимсити.

     
     
  • 4.25, Аноним (-), 14:56, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да хоть и на мезос, хоть это и некрасиво. Всё это по сути - таскраннеры.
     

  • 1.2, freehck (ok), 13:29, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кстати, каким молодчиком выглядит rhel: ни одной серьёзной уязвимости не выявлено. Вот только если debian - 79% рассмотренных контейнеров, а ubuntu - 16%, значит на rhel остаётся... 5%? Ясно-понятно. =)
     
     
  • 2.10, Аноним (-), 13:53, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кстати, каким молодчиком выглядит rhel: ни одной серьёзной уязвимости не выявлено. Вот
    > только если debian - 79% рассмотренных контейнеров, а ubuntu - 16%,
    > значит на rhel остаётся... 5%? Ясно-понятно. =)

    Молодец, возьми с полки пирожок ;)
    А на самом деле выглядит это так, что возможно было рассмотрено (а возможно и не рассмотрено, по причине очень сильной "необходимости") до 5% образов обозначенной Вами организации.

     

  • 1.3, Аноним (-), 13:35, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вот, еще в одной помойке нашли кучу дырявого софта, а все потому-что хыпстеры не могут осилить lxc и самостоятельно готовить контейнеры для соих целей
     
     
  • 2.7, freehck (ok), 13:42, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да тут дело даже не столько в создании контейнеров, сколько в том, что на их сопроводжение естественно кладётся болт.
     
     
  • 3.33, анонимус вульгарис (?), 15:35, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А чего там сопровождать? Они по определению одноразовые. Те, кто используют один контейнер дольше 10 минут, — ССЗБ.
     
     
  • 4.40, Аноним (-), 16:03, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А чего там сопровождать? Они по определению одноразовые. Те, кто используют один
    > контейнер дольше 10 минут, — ССЗБ.

    А у меня время жизни контейнера соизмеримо с временем жизни хоста.

     
     
  • 5.45, анонимус вульгарис (?), 17:19, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда на фига докер? С него весь профит в том, что контейнерами можно жонглировать как хошь. Если это не нужно, LXC будет более адекватным решением.
     
     
  • 6.47, Аноним (-), 17:51, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > докер
    > LXC

    Теорему Эскобара доказываете?

     
  • 2.8, Аноним (-), 13:44, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Я один из тех хипсторов, готовивший контейнеры самостоятельно. До появления доскера, разумеется. Потом перестал.
    Но ты ведь пцон ровный и правильный, сам пишешь ось, прикладное и даже системное ПО под каждую задачу на каждой ЭВМ. Повторное использование чужого труда - не нужно, так ведь?
     
     
  • 3.11, pkdr (ok), 13:56, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как показало данное исследование, как минимум 11% докеровских контейнеров не повторное использование чужого труда, а повторное использование чужих криворукости, лени и наплевательского отношения к безопасности.
     
     
  • 4.16, Аноним (-), 14:08, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    11% - очень даже неплохо, как для начала.


     
     
  • 5.49, анонимус вульгарис (?), 18:39, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так это не начало, а продолжение. В начале было 23%. Читайте в новостях не только заголовки.
     
  • 3.21, Аноним (-), 14:36, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    до появления докера это называлось chroot и почему вы считаете что до докера только вы это готовили не понимаю, на chroot наяривали до прихода во фрю джэйлов и в последствии зон в соялрку.
     
     
  • 4.26, Аноним (-), 14:59, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да, у меня это был чрут, и не полновесный, а сильно усечённый, но с докером сегодня удобнее. Я так и не понял чего вы не поняли.
     
     
  • 5.51, Аноним (-), 18:54, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    почему вы себя хипстером называете?
     

  • 1.4, Аноним (-), 13:35, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Да плевать, разве не для этого придумали изолированные контейнеры?
     
     
  • 2.6, freehck (ok), 13:40, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну то есть то, что твой контейнер потенциально делает из твоей машинки звено ботнета для рассылки спама, ддоса или ещё чего - тебя не волнует, ибо "основная система изолирована"?
     
     
  • 3.48, username (??), 17:55, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Потенциально любой необслуживаемый сервер тоже звено ботнета, давайте все потушим?
     
     
  • 4.50, анонимус вульгарис (?), 18:41, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Потенциально любой необслуживаемый сервер тоже звено ботнета, давайте все потушим?

    Давайте. Если б они были кому-нибудь нужны, их бы обслуживали.

     
     
  • 5.66, username (??), 12:48, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    рили? похоже ты не умеешь в реальность.
     
     
  • 6.71, анонимус вульгарис (?), 18:52, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это кто-то не умеет в автоматизацию.
     
  • 3.75, Анон007 (?), 21:42, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну то есть то, что твой контейнер потенциально делает из твоей машинки звено ботнета для рассылки спама

    То же самое делает не обновленный вовремя пакет, или устаревший пакет из репозитория.

    Проблема из сабжа не есть проблема контейнеров, как и устаревшие пакеты в репозитории не проблема пакетного менеджера. Это проблема - майнтенера и политики докерхаба. Естественно в данной ситуации внимательно смотреть что ты качаешь и запускаешь.

    Контейнер из доверенного источника может послужить на пользу. Например, в нем можно запустить последний зафикшеный Nginx, обновленная версия которого еще не появилась в оф. репозитории или она вообще не появиться. Так что технология полезная если пользоваться с включенной головой.

     
     
  • 4.77, freehck (ok), 06:42, 17/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Просто нет. Контейнеры нужны не для деплоя серверов. Это какие-то извращенцы придумали. Они нужны для того, чтобы в изолированном окружении заупстить какую-нибудь проприетарщину, например. Или для быстрого формирования сборочного окружения. Но почему вы серверы деплоите? Идея сродни снапу, не иначе.

    А пример с nginx любопытен тем, что абсолютно не понятно, на кой чёрт тебе там докер-контейнер. Ну вышел патч, ну собери и установи через checkinstall. Это ведь лучше, чем запустить последний зафикшенный nginx работать с уязвимым окружением в контейнере?

     
     
  • 5.78, пох (?), 08:45, 17/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет. Просто нет. Контейнеры нужны не для деплоя серверов. Это какие-то извращенцы
    > придумали.

    увы, девопы это придумали. В смысле докера, для остальных были lxc+openvz. И всякие atomic hosts они же.
    идея на бумаге была очень красива - вместо dependency hell внутри системы (три версии пехепе по номерам, две - по версиям одинаковы но в них разные версии шибконужного кривого модуля, и смотри не перепутай, с каким префиксом запускать pecl - кстати, как у тебя с умением собирать pecl'овые автопонатащеные зависимости в пакет, будь он деб или rpm? И то же самое с пихоном (там с модулями попроще, но есть пара своих, где баг исправили, версию не поменяли, не забудь стереть старые .egg везде где их ухитрилось отложить - напоминаю, оно умеет гадить под себя) - ну и там, по мелочи, три boost'а, скажем. Нет, это я не из пальца высосал, это я в старую шпаргалку глянул) получаем законченные черные ящички, из которых можно _автоматически_ (чего у тебя нет с lxc и прочей виртуализацией) собрать правильную этажерочку, а если кто под себя чем нагадил - оно откладывается на промежуточный слой.

    > А пример с nginx любопытен тем, что абсолютно не понятно, на кой чёрт тебе там докер-
    > контейнер.

    пример дурацкий, да - если тебе нужно и ты успеваешь до майнтейнеров дистрибутива, пора бы и собственным репо озаботиться, с правильно и вовремя собранным.

    но вот хатю не просто нгынх, а нхынх собранный с boring ssl "как у больших" (и мне тут модуль по дружбе подогнали от этого большого, который только с ним живет). При этом не сломай мне какой-нибудь curl, который дергает скриптомашина, причем не через бинарник, а через lib, и еще стотыщ запчастей, о которых ты можешь даже и не знать (и нет, вот это все пересобирать вручную из-за ssl не хотю, к тому же оно может собраться, но не работать). И нет, ДВА раздельных /etc/ssl - тоже не годится.

     

  • 1.12, Аноним (-), 13:56, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных версий пакетов и лечатся банальным apt update && apt dist-upgrade. Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой, который хорошо если светит наружу одним портом? В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.
     
     
  • 2.14, pkdr (ok), 14:06, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных версий пакетов и лечатся банальным apt update && apt dist-upgrade.

    Вот только хипстеры выше таких скучных вещей, как обновление ПО.

    > Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой, который хорошо если светит наружу одним портом?

    Совсем недавно пролетала новость про 100500 вывешенных в мир контейнеров с монгой.

    > В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.

    Вот только на практике я встречал много больших и крупных компаний, где используют первый попавшийся образ аргументируя "ну оно же работает, и так сойдёт"

     
     
  • 3.17, Аноним (-), 14:12, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1 - сам себе противоречишь
    2 - да, это проблема контейнеров... ну-ну...
    3 - сиска, нетфликс, эрикссон, властелины епама, властелины сцыклума. Ну, это так, навскидку, что инсайдеры поведали.

     
  • 3.56, vitvegl (?), 21:59, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Совсем недавно пролетала новость про 100500 вывешенных в мир контейнеров с монгой.

    А при чем здесь Docker?

     
  • 3.65, Zarat (ok), 11:16, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот только хипстеры выше таких скучных вещей, как обновление ПО.

    Когда насяльника требует, чтоб вчера контейнер был запущен, а сегодня в него только целевое содержимое подогнали, то "обновление ПО" это очень второстепенная задача.
    За всех судить не берусь, но в случае умения расставлять правильно приоритеты, на обновление ПО приходится забивать.
    Это я проективно, работаю не в ИТ

     
  • 2.20, Клыкастый (ok), 14:34, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > и лечатся apt update && apt dist-upgrade

    т.е. сначала заворачиваем в докер чтоб "поставил и забыл", а потом не забываем и обновляем? решение: в докерах которые обновляем ставим докеры, которые поставил и забыл!

     
     
  • 3.27, Аноним (-), 15:07, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет.

    - apt update && apt upgrade - в докерфайле на сборочнице. Обновление - это сборка нового образа.
    - остальное - при перезапуске контейнера/пода.

     
  • 3.28, Аноним (-), 15:08, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> и лечатся apt update && apt dist-upgrade
    > т.е. сначала заворачиваем в докер чтоб "поставил и забыл", а потом не
    > забываем и обновляем? решение: в докерах которые обновляем ставим докеры, которые
    > поставил и забыл!

    Ты, наверное, не в курсе, но решается это действительно просто. Dockerfile всего лишь начинается со строк:

    FROM ubuntu:16.04
    RUN set -x \
    && apt-get -y update \
    && apt-get -y upgrade \
    && apt-get install -y --no-install-recommends ...

    после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых кричат окружающие. Совсем ленивые могут две команды по сборке и заливке образа в крон запихнуть.

     
     
  • 4.31, Клыкастый (ok), 15:33, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых
    > кричат окружающие. Совсем ленивые могут две команды по сборке и заливке
    > образа в крон запихнуть.

    проблема не в том, что я знаю или не знаю. проблема в том, что часть раздающих докеры про это не знает, да и часть потребляющих тоже.


     
     
  • 5.41, Аноним (-), 16:05, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот и не волнуйся. Тебе это всё равно не грозит.
     
     
  • 6.52, _ (??), 19:04, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На него навалятся 100500 ботов с каждого из 100500 докер-контейнеров поднятых школотой. А это уже серьёзно.
     
  • 6.58, Котофалк (?), 23:56, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а мне, мне тоже не волноваться? а то я волнуюся: вдруг мне нужно волноваться?
     
  • 4.46, анонимус вульгарис (?), 17:28, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Dockerfile всего
    > лишь начинается со строк:
    > FROM ubuntu:16.04
    > RUN set -x \
    >  && apt-get -y update \
    >  && apt-get -y upgrade \
    >  && apt-get install -y --no-install-recommends ...
    > после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых
    > кричат окружающие. Совсем ленивые могут две команды по сборке и заливке
    > образа в крон запихнуть.

    Да-да, берём дырявый образ, обновляем его дырявым apt и плодим ноды ботнета.

    > Из опасных уязвиомостей лидером стали проблемы <...> CVE-2016-1252 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-1252.html) в <...> apt, которые встречаются в 5% рассмотренных образов.

     
  • 4.62, Аноним (-), 01:25, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вы докером-то пользовались хоть раз? пересборка такого докерфайла приведет к тому что докер возьмет закешированную версию предыдущей сборки, а значит все дыры будут на месте.
     
     
  • 5.80, Jack (??), 14:41, 19/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я в свое время с этим боролся. обновляя таймстамп в комментарии в докерфайле. Докер после этого считает, что это уже новый докерфайл, и не берет ничего из кешей.
     
  • 3.81, Нониус (?), 10:14, 22/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а потом не забываем а забиваем.
     
  • 2.59, пох (?), 00:24, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных
    > версий пакетов и лечатся банальным apt update && apt dist-upgrade.

    и кто же собирается это делать - в каждом инстансе каждого контейнера, который тебя угораздило запустить?

    > Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой,
    > который хорошо если светит наружу одним портом?

    потому что если в этот порт (или в десяток забытых собирателем контейнера соседних) нельзя засунуть ломающий xml - значит, в контейнере просто лишняя библиотека (что возможно, конечно). А если она таки нелишняя - то добро пожаловать в те 11%.

    > В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.

    а нахрена тогда? В сколько-нибудь сложном продакшне обычно не идет речи о запуске на одном хосте ста контейнеров, в нем идет речь о "как бы нам еще и вот эту хреновину распилить, чтобы можно было запускать ее на стойке серверов, а желательно на двух, на разных континентах".
    Контейнер в этом случае удобен только тогда, когда за тебя его уже кто-то собрал.

     

  • 1.35, Антон (??), 15:45, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    вобщемта
      git pull Dockerfile
      docker build
      docker run
    не особо сложнее
      apt-get update
      apt-get upgrade
      systemctl restart

    Надо только смотреть что в докерфайле и использовать официальные образы.
    Первичная настройка сложнее, зато потом удобно разворачивать.

     
  • 1.36, username (??), 15:49, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Желаю видеть такие-же регулярные отчеты об анализе на уязвимости каталога дополнений вротпресс и друпал. Иначе эта вся кампания как-то странно выглядит.
     
     
  • 2.60, пох (?), 00:28, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Желаю видеть такие-же регулярные отчеты об анализе на уязвимости каталога дополнений
    > вротпресс и друпал.

    как ты докера-то обocрал...

    > Иначе эта вся кампания как-то странно выглядит.

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

    контейнеры - только если вот автоматически чем-то проверять, без гарантий, при этом.
    (не говоря уж про сам докер, который тоже в принципе неанализируем)


     
     
  • 3.67, username (??), 12:57, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> Иначе эта вся кампания как-то странно выглядит.
    > как бе дополнения к вордпрессу вполне себе компактны и поддаются человеческому анализу
    > (поштучно, конечно, а не когда тебе внезапно достался сайт с неведомым
    > их количеством)
    > контейнеры - только если вот автоматически чем-то проверять, без гарантий, при этом.
    > (не говоря уж про сам докер, который тоже в принципе неанализируем)

    Вся ручная проверка контейнера укладывается в {yum, apt} upgrade. Просто кто-то предпочитает доверять поставщику реп, а кто-то после этого этапа еще запускает тулзы для доп проверок.
    Тред пестрит страхами тех кто ничего не понимать в том что такое контейнер но точно быть уверенным что это зло и дыра.
    Необновленный контейнер сейчас такая-же популярная штука как и необновленный сервер, решаеют эту проблему одинаковыми методами, с безопасностью - аналогично. Здесь и обсуждать нечего.

     
     
  • 4.69, Аноним (-), 18:06, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и так со всеми стапятьюдесятью контейнерами, которые понадобились именно на этой... большой текст свёрнут, показать
     
  • 4.72, анонимус вульгарис (?), 19:00, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Необновленный контейнер сейчас такая-же популярная штука как и необновленный сервер, решаеют
    > эту проблему одинаковыми методами, с безопасностью - аналогично. Здесь и обсуждать
    > нечего.

    Это справедливо для традиционных контейнеров, где крутится полноценная система (в том числе cron или другой демон, ставящий обновления безопасности автоматом), но не для докер-контейнеров, в которых традиционно запускается единственное приложение, и которые обновляются путём разворачивания свежего образа.

     
     
  • 5.73, пох (?), 20:29, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Это справедливо для традиционных контейнеров, где крутится полноценная система

    у полноценной системы как раз есть полноценный автообновлятор, если его специально не сломать.
    А у докер-контейнера ничего нет, и доступа в сеть нормального тоже - кроме упомянутого выше "единственного порта, на котором слушает [дырявая] монга".

    Ну и у полноценной системы - полноценные админы, с полноценной ответственностью. А не девелоперы, которым срочно нужно почесать зависимость от очередного неведомого нагромождения хлама, а если что - "мы не виноватые, оно шамо приполжло".

     

  • 1.44, YetAnotherOnanym (ok), 17:01, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Короче, всё как всегда: хочешь хорошо - сделай сам.
     
     
  • 2.70, Аноним (-), 18:28, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Короче, всё как всегда: хочешь хорошо - сделай сам.

    самому на порядок проще воспользоваться полноценным отдельным сервером/виртуальным/lxc/ovz/банальным сhroot в зависимости от необходимой степени изоляции (и уровень этой необходимости оценить самому, под конкретную задачу).

    докер и паблик репо становятся нужны, когда сделайсам не прокатывает по причине ограниченности ресурса самоделкина, а система сложная и "должна работать".

     

  • 1.53, ALex_hha (ok), 20:57, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Ну классика ж

    Docker - это отличная возможность переложить проблемы поддержания  актуальных версий системных библиотек (того же самого openssl) с  поставщиков ОС и системных администраторов на никого. После того, как  проблемы безопасности окружения переложены на никого, скорость внедрения  и эксплуатации заметно возрастает, ведь производительность никого  ограничена только супремумом пофигизма, а он, в свою очередь, верхней  границы не имеет (с)

     
     
  • 2.61, пох (?), 00:44, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну классика ж

    amarao неточен. Надо было поставить точку после "возрастает".

    > производительность
    > никого  ограничена только супремумом пофигизма, а он, в свою очередь,

    пофигизм тут не причем.
    Даже если тебе НЕ пофиг, как только ты начал таскать контейнеры из репо (неважно, общедоступного или корпоративного), а не собирать их сам (что в случае докера, мягко говоря, странная идея) - у тебя уже нет никакой физической возможности уследить за их содержимым. Справиться бы хотя бы с тем, чтобы вовремя сами контейнеры обновлялись, и ничего при этом в системе не порушить...

     

  • 1.54, ALex_hha (ok), 21:01, 15/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще частично проблему решает интеграция в CI сканеров, например - https://github.com/coreos/clair
     
  • 1.64, Аноним (-), 10:49, 16/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    По-хорошему нужно использовать образы наследованные от Alpine Linux, там будет меньше дырявого хлама
     
  • 1.68, ALex_hha (ok), 13:17, 16/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > у тебя уже нет никакой физической возможности уследить за их содержимым.

    а кто мешает после сборки образа запустить тот же ansible playbook и убедиться, что у вас нет уязвимых версий пакетов?

    > По-хорошему нужно использовать образы наследованные от Alpine Linux, там будет меньше дырявого хлама

    а там что, какие то другие версии apache/php/java? Они не подвержены уязвимостям?

     
     
  • 2.76, пох (?), 00:54, 17/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > а кто мешает после сборки образа запустить тот же ansible playbook и убедиться,
    > что у вас нет уязвимых версий пакетов?

    отсутствие внутри скачанного из репо-помойки образа ansible, плейбука к оному с учетом особенностей всех неведомых дистрибутивов, на основе любого из которых може быть собран контейнер, достаточных прав в конфиге.

    итого на каждый, приехавший по зависимостям образ, тебе надо - добавить ненужные в продакшн пермишны, добавить свои скрипты проверки, запустить, проконтролировать что они именно сработали, а не обломались о неверный угадав местного пакетного менеджера или еще какую специфичную проблему, если нашлась уязвимость - добавить _еще_ пермишнов чтобы таки суметь втащить апдейты (если они вообще есть, а не образ собран на базе давно неподдерживаемой ветки), убрать все пермишны, кроме дефолтных, и можно вздохнуть спокойно, пока не приедет следующий.
    Я даже верю, что это, в принципе, можно процентов на 90 автоматизировать, блокируя раскатывание на прод оставшихся 10 до ручного вмешательства. Правда, понадобится _очень_ изрядный запас процессорной и дисковой мощности, очень немалое время квалифицированного э...назовем это девопом, и понимание руководства, чем это ты тут занимаешься третий месяц, когда поставлена задача "перейти на использование docker вместо этих ваших костылей и подпорок".
    Но не верю, что где-то это сделано.

    Истории успеха, по прежнему, хотелось бы услышать.

     

  • 1.79, ALex_hha (ok), 19:33, 17/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    у нас в проде используется два дистра ubuntu 14.04/16.04. Так что никаких проблем нет. Если у вас зоопарк, то кто вам виноват
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру