Народная примета гласит - видишь какие-то странные майки на ARM-девелоперах ядра Linux, значит наш коллега, велосипедист и редхатовец, Jon Masters, как обычно, что-то этакое сказал.

В этот раз он, описывая ужас без конца, царивший в ARM-мире до введения им стандартов, сообщил, что сепаратисты ARM-мира не хотят унификации, посылая патчи со своими cute embedded nonsense hacks в LKML. В целом, в ARM-мире бардак еще тот, но посылать патчи в LKML - можно ли пасть ниже?

ARM-коммьюнити предсказуемо стало оправдываться, что мол все посылают патчи в LKML, просто не все говорят об этом. И вообще, по опросам несколько процентов взрослых людей хоть раз посылали патч в LKML, и не считают это ненормальным. Но мы-то знаем!

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

Из других ARM-новостей, AMD продолжает продолжать переходить на ARM. Они анонсировали выход Developer Kit с будущим Opteron на AArch64/ARM64. Стоит довольно мало для своего класса - примерно 5 биткойнов по нынешнему курсу. В качестве рабочей операционной системы там, как мы и говорили, используется Fedora. Кстати, посмотрите январскую презенташку, если не видели:



То, что используется Fedora, нас нисколько не удивило. Другие производители, например Cavium, сотрудничают с нами, чтоб впереди всех конкурентов добиться работы Fedora на их оборудовании. Все, разумеется, происходит прозрачно и публично, в рамках нашего Fedora ARM SIG. Так что если вам интересно, куда движется серверный ARM, присоединяйтесь к нам.

Ну чтоб окончательно убедить колеблющихся вендоров, нерешительно топчущихся со своими 32-битными cute embedded nonsense hacks у входа в мир светлого будущего, Red Hat объявила о специальной партнерской программе для производителей ARM-оборудования. В рамках этой программы партнеры получают доступ к горячему наисвежайшему ПО, прямо из Koji и git, и помощь специалистов Red Hat в процессе разработки платформ. Нам кажется, что предложение стоящее. Интересно, обратят ли внимание на хорошие условия предложения создатели отечественного национального микропроцессора Baikal?

Создали и такую команду - Fedora Security Team. Коллеги-аналитики уже обсуждают новость на OpenNET.ru. Уже состоялось учредительное собрание, на котором раздали задачи:

  1. Sparks to send a message to the list asking people to add themselves to the roster
  2. ignatenkobrain to write a script to somehow get stats from BZ and use them for the badge system
  3. ignatenkobrain to write a script to somehow get stats from BZ and use them for "hall of fame" FST wiki page
  4. ignatenkobrain to request git repo for FST scripts


Вышел LibreOffice 4.3. Новость уже обсуждают на Linux.org.ru. Хотелось бы добавить, что к этому релизу компания VRT Systems приурочила выход версии 1.2.0 их свободного клип-арта для рисования схем сетей в LibreOffice/OpenOffice.org.

Martin Pitt, один из немногих разработчиков Canonical, начал работу по интеграции LXC и systemd.

Кто пропустил 10-летие Ceph, почитайте пост про его историю. Кстати, недавно Red Hat выпустила первый коммерческий продукт на базе Ceph после покупки Inktank.

Появилась первая хаутушка, как запустить Kubernetes на CoreOS - первая часть и вторая. Кстати, Kubernetes теперь умеет управлять кластерами Vagrant.

Завершилась конференция пользователей и разработчиков GNOME, GUADEC 2014. Наших коллег, само собой, там было навалом. Из отчетов посоветуем почитать, что пишет Jiří Eischmann - первый день, второй, третий, четвертый. Вкратце, что заметил Jiří:

  • UX в GNOME, и тестирование на живых людях.
  • Подсистема геолокации, приватность и kdbus.
  • Биндинги к LibreOffice.
  • Введение в workflow GNOME-разработчика для начинающих от Марины Журакинской.
  • Pitivi. Как образование маркетолога помогло разработке, и как не помогает в фундрайзинге.
  • Обзорный доклад про ПО для автомобилей, и где тут притулиться OSS.
  • Планы на Web (бывший Epiphany) и WebKitGTK.
  • GNOME Boxes.
  • Fleet Commander - спосо разворачивать и настраивать GNOME в больших инсталляциях.
  • Низкоуровневые компоненты GNOME, Wayland.
  • Поддержка оборудования в GNOME. Мало того, чтоб был написан драйвер - надо начать использовать доступный функционал в пользовательских приложениях, например показывать геолокацию.
  • Matthew Garrett изложил свое видение того, куда надо двигаться GNOME.
  • Новая среда разработки для GNOME - Builder. Коллеги-аналитики уже обсуждают на OpenNET.ru.


В завершение обратим внимание на пост, написанный по мотивам выступления на GUADEC 2014, про новый canvas для GNOME, идущий на замену Clutter.

Яндекс проводит хакатон с 9 по 10 августа. Обратите внимание, не 9 и 10, а с 9 по 10:

О мероприятии 9-10 августа в Яндексе пройдёт хакатон. Если вы хотите за выходные создать новый продукт или интересную фичу, берите друзей и приходите в офис Яндекса. Хакатон состоится в рамках мастерской Tolstoy Startup Camp.

Вы можете участвовать в хакатоне индивидуально, привести свою команду или найти её на месте. На этот раз мы решили не вводить никаких ограничений. Можно использовать любой язык программирования, любые инструменты и дать волю фантазии — работайте над тем, что вам действительно интересно. В вашем распоряжении целых 24 часа. С вас — энтузиазм и время, с нас — комфортная обстановка, доступ к экспертам, пицца и компания единомышленников.

Мероприятие начнется в 13:00. После представления жюри и презентаций проектов вас ждёт самое интересное — марафон программирования длиной в сутки, с 17:00 субботы до 17:00 воскресенья.

Когда: 9-10 августа

Где: московский офис Яндекса, БЦ «Ринко Плаза»

Для участия в хакатоне каждый человек должен пройти регистрацию.

Она закроется 5 августа в 18:00 по московскому времени.


Некоторые из нас подумывают принять участие, чтоб спокойно поработать над задачками Fedora. Если, конечно, успеем придумать что-то конкретное и успеем зарегистрироваться.

Вышел DNF 0.5.5. В этой версии изменений в самом DNF немного. Можно выделить лишь улучшение работы через proxy-серверы, в т.ч. и добавление нового функционал в API. Но особенно интересное изменение внесли не в DNF, а в низкоуровневые библиотеки.

Igor Gnatenko заметил странную разницу в том, как работает Yum и DNF c пакетами, которые разбили на несколько других, и разбирательство привело в итоге к серьезным изменениям не только в Fedora.

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

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

Мы требуем, чтобы изменения не нарушали работу текущих инсталляций. Т.е. пользователь, у которого NetworkManager использовал функционал, выделенный в отдельную часть, не должен заметить нарушений работы. В его случае, после разбиения, при обновлении должны установиться и новые пакеты. Иначе используемый им функционал будет недоступен. Мы это делаем так - в случае разбиения, во все пакеты, полученные из старого "монолитного", мы добавляем Obsoletes: %{name} <= 1.2.3-1. Получается так - был пакет shiny, а получилось два новых - shiny и shiny-test (выделили часть из shiny сюда). Благодаря тому, что оба пакета теперь содержат Obsoletes, yum использует их оба для обновления со старого. Т.е. по команде sudo yum update shiny если yum увидит, что старый пакет чем-то Obsoletes, то он найдет все новые пакеты с такой директивой и поставит их все вместо старого. Если же старого пакета не было (установка с нуля), то Obsoletes нечего, и он будет ставить лишь главный пакет. Таким образом на старых инсталляциях функциональность будет доступна как и раньше, а на новых будет установлена только нужная часть.

DNF поступает не так. По команде sudo dnf update shiny он сначала вычислит дерево обновлений, чему удовлетворит лишь новый пакет shiny. И не будет нужды ставить sniny-test. Поэтому у пользователей пропадет функциональность, выделенная в пакет shiny-test. Т.е. Yum сначала вычисляет Obsoletes, затем обновляет, а DNF наоборот - сначала обновляет, затем вычисляет Obsoletes.

Нельзя сказать, что правильнее с т.з. теории, но использование стратегии из Yum точно лучше с т.з. практики. Иначе обновления (и переименования qt→qt3 и qt4→qt) потребуют большого количества ручных операций и двойных изменений в SPEC-файлах. После обсуждения с разработчиками openSUSE, поведение Yum было реализовано в libsolv и уже доступно в Fedora 21 и выше. К сожалению, Fedora 20 пока использует более старый GIt-снапшот, так что поведение DNF в ней не совпадает с Yum - мы вас предупредили!

Gartner в очередной раз опубликовал свой анализ рынка виртуализации x86-систем. К сожалению, несмотря на обилие информации, они не визуализируют изменения, приводя лишь график с текущим состоянием. Но, к счастью, Vladimir Eskin аккуратно собирает раздаваемые Gartner графики, и рисует тренды, снабжая авторскими комментариями:



Это не доля рынка, и не какие либо финансовые показатели, а некое агрегатное значение, вычисляемое по разным факторам, чья величина оценивается экспертами Gartner. По ссылке можно ознакомиться, как они его получают.

В целом динамика, если верить экспертам, довольно понятна. Citrix с их Xen теряет влияние. Microsoft захватил свое и держит (Windows просто очень много на рынке). Oracle с их модифицированным Xen немного сдали (и нам кажется, что сдадут еще сильнее в ближайшее время). Huawei сейчас переходит с Xen на KVM, и дела у них наверное пойдут хорошо, но по одной точке пока построить какие-то предсказания не получается. Очень рады за положительную динамику Parallels - сейчас они пробуют подружить OpenStack и контейнеры, и мы уверены, что их влияние на рынке будет лишь увеличиваться. Ну и Red Hat ровненько движется в правильном направлении.

Лидерство VMware тоже вполне понятно. Они в этой теме долго, и как только заметили опасность от OpenStack, то сразу же более-менее успешно начали переводить его из конкурента в союзника, даже став заметным участником коммьюнити. Но, конечно, молодой OpenStack, как пишут, уже начинает отъедать долю VMware (имеется в виду чисто проприетарных продуктов гиганта виртуализации).

Вообще, общий тренд понятен - на рынке заправляют два лидера, к которым стремительно подбирается OpenStack в виде букета предложений. Всем это понятно, и к OpenStack присоединяется так много народу, что становится жутковато от объема нового кода, добавляемого в проект (кстати, на прошедшем FOSDEM 2014 был интересный доклад на тему тестирования OpenStack). Из последних неожиданных присоединений к проекту можно выделить SAP, который будет подшлифовывать OpenStack под свои ультра-энтерпрайзные продукты. А к сетевой части подключилась Cisco. Они теперь занимаются политиками SDN в OpenStack на основе предложенного ими же протокола OpFlex.

Характерно, что хотя Cisco и могла бы навелосипедить свой (полу)проприетарный вариант, но они решили предложить сообществу открытый вариант. Можно смело говорить, что понимание того, что SDN должен базироваться на открытых технологиях, уже давно овладело сознанием людей, принимающих решения. Например, послушайте недавнее интервью Neela Jacques, директора проекта OpenDaylight:



Ну и чтоб два раза не вставать - недавно вышедшее "Software-defined Storage" OpenStack Swift получило новые политики управления. Автоматически они не включаются, но наружу теперь торчит API, которым можно воспользоваться, чтоб ими управлять. Как пример, теперь можно по cron гонять данные в зависимости от их возраста с одного хранилища, на другое, согласно бизнес-логике. Можно учитывать географическое распределение хранилищ, типы носителей (например, дорогой и быстрый SSD, или медленные и надежные перфокарты или флоппи-диски). Звучит, конечно, неособо фантастично, но здорово, что наконец-то и этот функционал появился.

Наш коллега, Lars Kellogg-Stedman, опубликовал поучительную историю, как он натолкнулся на регрессию в ядре, мешавшую ему использовать Docker, и вооружившись git, qemu, gdb и Docker, нашел ее причину. Вкратце, наш коллега ее и создал. Заметка очень ценна тем, что автор, столкнувшись с проблемой, не стал бегать кругами по форумам и чатикам, жалуясь на глюки (типичная картина для ряда отечественных айти-сайтов), а взял и поправил. Это что касается психологического момента, но автор еще и подробно описал те advanced методы, что они применил для максимальной автоматизации поиска регресии - ну да почитайте сами. Лично мы с интересом прочли про пару приемов, и взяли на вооружение. Нам, известным бета-тестерам, полезны навыки работы над ошибками.

Наш коллега, сбежавший из нашего ада перешедший работать в MoFo, Andrew Overholt, рассказал, как они провели первый Mozilla bootcamp. Основной проблемой, с которой сталкивается MoFo, это понижающийся Bus Factor команды разработчиков. Причин тому довольно много. Это, конечно, и странная лицензионная политика, и неоптимальная схема разработки (большое единое дерево, управляемое допотопной VCS - Mercurial), и гугле-подобный стиль работы с библиотеками, упрощающий жизнь для WIndows-разработчиков (не секрет, что организация MoFo, не их коммьюнити, а именно коммерческая компания, очень неровно дышит по Windows). Так или иначе, но Bus Factor нужно увеличивать, и было решено проводить буткампы, чтоб делиться знаниями с начинающими. Прошло достаточно хорошо, и Andrew делится тем организационным опытом, что они получили.

В OpenSSL начиная с Fedora 21 отключили по умолчанию SSL2 и SSL3. Это надо было сделать уже давно, но накатившийся вал проблем в открытых криптобиблиотеках, и их нынешнее печальное состояние, заставляли опускаться руки.

Небольшая задачка для программистов на Си. Какой тип у char по умолчанию - signed или unsigned? Наши коллеги жалуясь на жестокость этого мира делятся своими вариантами, а правильный ответ здесь.

Мы потихоньку догоняем другие коммьюнити по возможностям инфраструктуры. У нас появился Jenkins, и появился узел для тестирования собранных RPM - Taskotron. Это уже в ближайшем будущем повысит качество нашего ПО. У нас уже образы для облаков собираются автоматически, и хотелось бы их потщательнее проверять, прежде, чем они будут растиражированы сотнями тысяч штук по датацентрам.

Наши друзья из Пиратской Партии России собираются провести мероприятие, на которое всех приглашают.

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

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

Ну а раз уж мы встретимся, то после КриптоИнсталлФеста было бы разумно провести собрание Московского и Подмосковного отделения, обсудить как сущностные вопросы, так и формальные. В данный момент наш новый председатель регистрирует общественную организацию для последующей реорганизации в партию. Поэтому надо будет провести выборы руководящих органов. Место и точное время собрания пока не определилось, скорее всего, это будет бар-ресторан неподалеку от места проведения феста. Сообщаю вам это для того, чтобы вы заранее спланировали свое время.

Если вы хотите выступить на фесте или готовы помогать новичкам устанавливать программы, свяжитесь, пожалуйста, по почте pavel [cобачка] rassudov.net или по тел 8-903-223-82-71, 8-916-518-22-70.

2 августа с 12.00-18.00. Москва, Центр им. Сахарова, ул.Земляной вал, д.57, стр.6. Ближайшие ст. метро «Курская», «Чкаловская», «Таганская»

Подробная программа мероприятия по ссылке.

  • 12.00 — 13.00 Встреча гостей, начало Key Signing Party (Встреча для подписи ключей)*
  • 13.00 — 14.30 Выступление докладчиков
    • Угрозы цифровым правам. Саркис Дарбинян, адвокат Пиратской партии России. Право на тайну частной жизни, тайну переписки и доступ к информации в свете нового цифрового законодательства. Какие угрозы цифровым правам человека существуют сегодня. Законы и правоприменение.
    • Типичные блокировки. Примеры правоприменения. Дамир Гайнутдинов, юрист Ассоциации Агора. На примере нескольких реальных кейсов Дамир покажет, чем власти оправдывают ковровые блокировки сайтов, как ведут себя в суде представители Роскомнадзора и Генеральной прокуратуры, и почему, несмотря ни на что, нужно идти в суды.
    • UnCersorship Full Toolkit. Артем Козлюк, РосКомСвобода. Наиболее полный список инструментов обхода интернет-цензуры. Tor, i2p, VPN, плагины, приложения и прочие хитрости.
    • Криптовалюты и электронные деньги. Сергей Матвеев, программист, хакер и шифропанк. Мифы о причислении BitCoin к криптовалютам. Так ли он анонимен, безопасен, быстро обрабатывается и децентрализован.
    • Строим самоорганизующуюся mesh-сеть. Иван Донин, Meshroom. Практическое применение mesh-сетей и обзор проекта meshroom.ru
    • Презентация проекта Mirrolist. Shara, основатель проекта Блоку нет! Презентация проекта Mirrolist, который оказывает помощь в зеркалировании clearnet ресурсов в darknet сетях. А также несколько советов по оптимизации сайтов для зеркал.
  • 14.30 — 15.00 Видеосвязь с Руной Сандвик, сотрудником Tor Project.
  • 15.00 — 16.00 Лекция «Технологии современной анонимизации». Сергей Матвеев, программист, хакер и шифропанк. О тонкостях работы proxy, VPN, Tor, I2P, FreeNet, GNUnet, opennet, F2F и многом другом.
  • 16.00 — 19.00 Воркшопы по установке СПО, программ для шифрования и помощь их освоении.


ПРИНОСИТЕ СВОИ НОУТБУКИ!

Вам помогут установить и освоить программы, позволяющие зашифровать информацию на своем компьютере и свое общение, установить Ubuntu и другое свободное программное обеспечение.

*Key Signing Party («Встреча для подписи ключей») — это собрание людей, которые используют систему шифрования PGP для взаимной проверки личности, владеющей ключом, и подтверждения своей подписью ключей друг друга. KSP позволяют расширить сеть доверия и образовать в ней дополнительные связи. Подпись ключей будет осуществляться во время встречи гостей, а также во время перерывов между выступлениями участников.

Добавляйтесь в группы в социальных сетях, чтобы следить за новостями:

Великобритания приняла решение о введении OpenDocument обязательным государственным стандартом. Учитывая, что российская т.н. "элита" ориентирована именно на Великобританию, у нас вновь разгорелись надежды, что уж теперь-то OpenDocument сделают стандартом и в РФ. Ну, как минимум, как то им теперь будет нужно узнавать, не внесли ли их в очередной санкционный список?

Без сомнения официальное решение одной из ведущих экономик мира переходить на OpenDocument подстегнет зависимые от нее страны, такие, как, например, РФ или Уганда (которая уже включила открытое ПО и стандарты в национальную "Information and Communication Technologies Policy"). Организация "The Document Foundation" уже поблагодарила правительство Ее Милостивого Величества Елизаветы II, Божией милостью Соединённого Королевства Великобритании и Северной Ирландии и иных своих царств и территорий Королевы, Главы Содружества, защитницы веры, за прогрессивное видение, которое без сомнений подвигнет и другие правительства адаптировать открытые стандарты. А Европа пока отстает - мы уже говорили, что европейцы пока обсуждают смежные вопросы. Вероятно сказывается медлительность принятия решений при демократической форме правления по сравнению со скоростью в самодержавных государствах с вертикалью власти, строгой иерархией, и отсутствием оппозиции.

Эксперты Microsoft не стали придумывать ничего нового, а повторили обычную чушь, что "стандарты должны конкурировать", хотя понятно, что если "стандарты" начнут "конкурировать", то мы получим обычный бардак в стиле доковских файлов, открывающихся в разных вордах по разному. Учитывая, что за каждую копию ворда Microsoft получает деньги, с идеей про пучок стандартов вполне очевидно qui prodest.

Что важно, UK переходит не на Apache OpenOffice, LibreOffice или еще что, а, заметьте, устанавливает стандартный формат файлов. Открытость стандарта, а не десятков его аналогов, это и есть настоящая возможность выбора - если есть возможность и желание, то используй открытый пакет, а если нет - покупай проприетарное решение. Однако это и несет определенные временные опасности, о которых нас предупреждает Glyn Moody. Он пишет, что главное сейчас не впасть в головокружение от успехов. К сожалению, умирающий Apache OpenOffice еще активно используется, особенно Windows-пользователями, хотя из него уже давно сбежали все разработчики, кроме тех, кого корпорация IBM успела закабалить контрактами. И увы, но поддержка ODF там сильно отличается от LibreOffice. Повторяется ситуация с майкрософтовскими вордами - в одном приложении сохраняешь документ, а в другом он открывается неправильно. Это может серьезно испортить общественное мнение насчет открытых стандартов и возможностей, которые они несут.

В ЕС, конечно, не только плетутся в хвосте. Местами переход на открытые стандарты уже приносит серьезные деньги - в Тулузе благодаря переходу на LibreOffice наэкономили на миллион евро (уже обсуждают на Хабрахабре).

Мы уже упоминали про доклад Dan Walsh на тему Docker и SELinux, который он сделал на прошедшем DockerCon. Сразу после выступления, Dan написал статью, в которой тезисно изложил свой доклад.

Контейнеры не ограничивают

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

  • Я слышал, как люди говорили, что контейнеры Docker настолько же безопасны, как и запуск приложений в отдельной виртуалке.
  • Я знаю людей, которые загружают образы для Docker из интернета и запускают их.
  • Я даже знаю PaaS-провайдеров (не OpenShift), позволяющих клиентам загружать их собственные образы, чтоб запускать их на системах совместного использования.
  • У меня есть коллега, который сказал: "Docker предназначен для запуска под рутом неизвестно чьего ПО, скачанного из интернета."


— Ближе! Ближе, бандерлоги!

Немедленно прекратите считать, что Docker и ядро Linux защищают вас от вредоносного ПО.

Стоит ли вам беспокоиться?

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

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

С Docker-контейнерами стоит работать, как с "сервис-контейнерами" — это значит, что работать с Apache в контейнере точно так же, как с Apache, запущенном обычным способом. А это значит, что вам стоит поступать следующим образом:

  • Сбрасывать привилегии, как только можно.
  • Запускать сервисы не от root всегда, когда возможно.
  • Рассматривать привилегии суперпользователя внутри контейнера, как root снаружи контейнера.


Сейчас мы рекомендуем участникам Common Criteria рассматривать привилегированные процессы в контейнере, точно также, как привилегированные процессы снаружи контейнера.

Не запускайте скачанные откуда-то образы для Docker на вашей системе. Я вижу множество схожестей между контейнерной революцией Docker и Linux-революцией 1999 года. В то время (да, и к сожалению сейчас - прим. перев.), когда сисадмин узнавал про интересное Linux-приложение, он обычно:

  • Искал в интернете пакет по ресурсам типа rpmfind.net, или вовсе по случайным сайтам.
  • Скачивал неизвестно кем и когда собранный пакет.
  • Устанавливал с помощью пакетного менеджера (или make install)
  • Запускал прямо под рутом


Что может пойти не так?

Типичный случай - спустя две недели после того, как сисадмин узнавал про уязвимость, скажем в zlib, и пока искал надеясь и веря, что его ПО неподвержено этой уязвимости, оно на самом деле еще как уязвимо.

Вот тут как раз и место и время, где Red Hat и несколько других игроков, которым доверяют, вступают в игру. Red Hat Enterprise Linux дает сисадминам:

  • Доверенный репозиторий, откуда можно скачивать ПО.
  • Своевременные исправления безопасности.
  • Команда Red Hat для поиска и исправления уязвимостей.
  • Команда инженеров для управления/поддержке пакетов и внедрения улучшений безопасности.
  • Сертификации системы по безопасности.


Запускайте только контейнеры полученные из доверенных источников. Я считаю, что вам следует продолжать пользоваться пакетами и кодом, полученными из тех же мест, что вы использовали раньше. Если же вы получили код не от этих источников, то не надейтесь, что контейнеры защитят вашу систему.

Так в чем же проблема? Почему контейнеры не ограничивают?

Основная проблема в том, что не все в Linux может быть разнесено по различным пространствам имен (namespace). Сейчас Docker использует пять namespace, для разделения процессов - Process, Network, Mount, Hostname, Shared Memory.

Хотя эти пять пространств имен дают нам некоторый уровень безопасности, он далеко не максимальный, как в случае KVM. В случае виртуальной машины, процессы не общаются с ядром хостовой системы непосредственно. Они не имеют доступа к файловым системам ядра, таким как /sys, /sys/fs, /proc/*.

Device nodes общаются лишь с ядром виртуалки, не с хостом. Поэтому, для повышения привилегий до выхода из виртуалки, процессу требуется взломать ядро виртуалки, затем найти уязвимость в гипервизоре, затем пробиться сквозь SELinux (sVirt), жестко контролирующий виртуалку, а уж затем начинать атаковать ядро хостовой системы.

Когда же вы запустили процесс в контейнере, он уже имеет доступ к хостовому ядру.

Основные подсистемы ядра, которые до сих пор не поддерживают namespace:

  • SELinux
  • Cgroups
  • /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus


Устройства, которые не поддерживают namespace:

  • /dev/mem
  • /dev/sd*
  • модули ядра


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


Страницы