Яндекс проводит хакатон с 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*
  • модули ядра


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


GCC получил премию ACM! Наших товарищей и коллег там полно, поэтому мы очень довольны. В разное время эту премию получали такие проекты, как LLVM, GHC, Jikes RVM (Research Virtual Machine), Coq, так что компания хорошая. От лица сообщества GCC премию поехали получать инженеры Nick Clifton (Red Hat) и David Edelsohn (IBM):



Полученный приз продемонстрировали затем на недавно прошедшем GNU Tools Cauldron в Кембридже, а полагающиеся деньги перечислили в FSF на развитие свободного ПО.

В котелке, кстати, доварилось очень много интересных идей (см. расписание мероприятия и тезисы выступлений) - объединение усилий разработчиков GCC с проектом LLVM, планы на Glibc 2.20 и 2.21, новости о GCC JIT (о котором мы уже упоминали), новые архитектуры и много чего еще.

Из других новостей про GCC - известный местный хулиган и матершинник, Linus Torvalds, не оценил последних новостей, и как обычно особо не выбирая возражения назвал GCC полным дерьмом.

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



Поддержка Tor пока экспериментальная, и возможно адреса будут изменены в будущем. Также мы планируем добавить и другие ресурсы.

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

А программисты все никак не соберутся заменить правительства на маленький скрипт, увы.

Страницы