Официально объявлено, что EPEL 5 отправят в архив с 31 марта 2017 года. Всё, наконец-то отмучались!

Участники Fedora празднуют окончание поддержки EPEL 5

Matthias Clasen продолжает знакомить нас с его проектом, приложением GNOME Recipes. Как понятно из названия, оно предназначено для управлениями рекептами приготовления еды. Несмотря на то, что не все опенсорс-разработчики удовлетворяются шаурмой, пиццей и колой/пивом, такого приложения в составе GNOME не было.

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

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

Все это напрямую затрагивает и нас, но, к сожалению, публично комментировать юридические вопросы по существу никто не будет. Тем не менее, участник Fedora Legal, юрист SFLC и патентный адвокат Red Hat, Richard Fontana, обозначил свою точку зрения по поводу такого радикального прочтения новых условия использования GitHub - это неправильная трактовка. Richard хорошо знаком с юристами GitHub, а они с ним, и благодаря такой дружбе, в GitHub следуют его советам (например, как указывает сам Fontana, в новом ToS GitHub явно используется предложенная Ричардом концепция "inbound=outbound").

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

Да, и удалять исходники мы с GitHub, разумеется, не будем.

Не так давно вышел SystemTap 3.1, и в честь этого события хотелось бы поговорить о тестировании.

Наш коллега, инженер Red Hat, David Malcolm, опубликовал заметку о том, как тестируется GCC, и какие можно ожидать улучшения. Напомним, именно он работал над включением unit-тестов в кодовую базу GCC.

Тестирование собранного ПО, это хорошо, но еще лучше, чтобы ошибки выявлялись на этапе компиляции. Еще один наш коллега, Martin Sebor, опубликовал заметку о том, какие можно использовать флаги GCC для поиска подозрительных мест в коде на ранних этапах сборки и привел примеры ошибок в коде, выявляемых при сборке с этими флагами.

Разработчик не обращает внимания на предупреждения компилятора

Вышел systemd 233 (и уже доступен в Fedora Rawhide).

В этот раз изменения (на русском, на OpenNET.ru)в основном сконцентрированы в systemd-networkd, поддержке контейнеров. Также systemd перешел на Python 3, а dbus-скрипты перенеслись из /etc в /usr. Вообще, изменений довольно много, и рассмотреть что-то огромное уже непросто.

Когда пытаешься прочесть ChangeLog к очередному релизу systemd

Студенты и аспиранты, внимание! Только что официально объявили список организаций-участников Google Summer of Code 2017. Если вы еще не решили, чем заняться летом, то это вполне достойное, интересное, и финансово полезное занятие.

Выбирайте интересный вам OpenSource-проект, в нем ищите интересную задачу (или предлагайте свою), и подавайте заявку.

На Хабрахабре продолжили публикацию статей, посвященную настройке SELinux:

Разработка SELinux-модуля для пользователя tutorial

Это вторая статья из цикла

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

Предположения

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

• Прочитал прошлую статью
• Имеет под рукой CentOS 7
• На котором установлены пакеты setools-console, policycoreutils-devel, selinux-policy-devel, policycoreutils-newrole
• И включен SELinux в режиме enforcing с политикой targeted или minimum

Это все про вас? Тогда поехали!

Пользователи и роли

Основное назначение пользователей — хранить список ролей, которые он может использовать. Пользователи по-умолчанию уже представлены в политике targeted или minimum, можете посмотреть командой semanage user -l.

Как известно из прошлой статьи, именно роли являются контейнерами для типов, а именно на типы вешаются все необходимые правила. Таким образом, пользователь просто расширяет это дерево, создавая больше возможных вариантов. Обратите внимание: если у пользователя есть та или иная роль, он может самостоятельно переключиться в нее, используя команду newrole. Таким образом, разрешив пользователю роль sysadm_r или unconfined_r, вы автоматически даете ему неограниченные права на систему.

Пользователи и пользователи

Между Unix-пользователем (тем, который имеет UID) и SELinux-пользователем (тем, который имеет контекст) есть тонкая связь, которой можно управлять при помощи команды semanage login. Связь это односторонняя: id -Z user1 вам ничего не покажет. Специальный пользователь __default__ обозначает всех пользователей, не перечисленных в системе.

Создание пользователя (простой способ)

Самый простой способ создать пользователя из готовых ролей — использовать semanage user -a. Предположим, нам нужен просто новый пользователь с дополнительным набором ролей:

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

Контекст

Об этом мало где пишут, но мало просто создать пользователя. Если его контекст отличается от default_context, для него необходимо настроить файл контекстов. Подробнее см. man user_contexts. Настроим файл и для webadm_u:

Проверка

Зайдем под пользователем webadm:

Сменим uid на 0 и попробуем что-нибудь «сломать»:

Сменим роль на webadm_r и попробуем теперь:

Что и требовалось доказать — мы сделали админа, который может админить только веб. К сожалению, количество ролей «по-умолчанию» сильно ограничено. Список можно посмотреть тут.

Создание пользователя (правильный способ)

Давайте сделаем все тоже самое, но например для администрирования docker, причем напишем его с нуля. Модуль будет очень простой. Что нам нужно разрешить?

1. Вход по ssh
2. Доступ к sudo (UNIX-права никто не отменял)*
3. Администрирование файлов, папок и сервиса докера
4. Исполнение бинарников докера (docker, runcon)
5. Коннект к сокету докера

Прим.: группа docker на последней версии CentOS7 не имеет доступа к /run/docker.sock по-умолчанию.

Напишем модуль и контекст-файл:

# новый модуль
policy_module(dockeradm, 1.0.3)
# объявляем новую роль
role dockeradm_r;
# стандартный шаблон для НЕ-админа
userdom_unpriv_user_template(dockeradm)
# разрешаем dac_override
allow dockeradm_t self:capability { dac_override dac_read_search };
# разрешаем sudo
sudo_role_template(dockeradm, dockeradm_r, dockeradm_t)
# разрешаем управлять файлами и папками контейнеров
container_admin(dockeradm_t)
# разрешаем исполнять исполняемые файлы контейнера
container_runtime_exec(dockeradm_t)
# разрешаем коннект к сокетам контейнера
container_stream_connect(dockeradm_t)
# макрос gen_user создает пользователя так-же, как semanage user -a
# он всегда должен быть в самом конце файла
gen_user(dockeradm_u, dockeradm, dockeradm_r, s0, s0)

Скомпилируем и установим модуль:

Настроим пользователя и контекст:

Проверим, что нас пускает в систему:

Проверим наши права:

Как говорит Apache, It works!

Подведение итогов

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

• selinux,
• setenforce 1,
• linux,
• centos,
• policy_module,
• user

Коллега, анонимный аналитик, анонимно пишущий анонимные посты в анонимном блоге (т.е. как ни крути, авторитетный и беспристрастный источник) продолжил морщить веревкой море любителей Docker.

За прошлый заход он прославился на всех иностранных онлайн-ресурсах про Open Source. К сожалению, нужно признать, что некоторые моменты резанули глаз.

А в этот раз он продолжил ниспровергать некоторые устоявшиеся стереотипы у любителей запустить неподдерживаемую версию PHP. Опять же, невозможно согласиться со всем, что пишет автор, но ознакомиться стоит. Очень интересно одно из его утверждений, что прямо сейчас в мире никто не использует Docker так, чтобы было одновременно в продакшене и успешно и без серьезных проблем. А вы такие примеры знаете?

Инженеры в целом положительно оценивают перспективы Docker

Устаревание POSIX, это не фантазия наших коллег, а суровая реальность. Стандарт устарел и для хранения данных, и для передачи данных по сети. Если по хранению данных у нас есть варианты, то на сетевую подстистему пока никто не покушался. До недавних пор.

Martin Sustrik, инженер Google и коллега Pieter Hintjens по разработке ZeroMQ, предложил переработать BSD sockets API. Он создал репозиторий на GitHub, в котором выложил первый вариант предложенных изменений и ряд примеров.

Подозреваем, что любителей юниксвэя ждут тяжелые времена в этом году.

Наш коллега, Nathaniel McCallum, уставший от нестабильной работы Bluetooth в Fedora, занялся созданием тестовых сценариев для Bluetooth-устройств.

Проблема в том, что поддержка Bluetooth разбивается на ядро (где никто ничего не тестирует, напомним) и userspace, а пользователь просто видит, что устройство не работает, и пишет точно так же в багзиллу - "устройство XXX не работает".

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

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