⌨ Labor omnia vincit ☮

Russian KDE community

Posted in KDE, SuSE [ru] by anaumov on 20.09.2018

KDEНаконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое? 🙂
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами,  было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.

Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.

Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.

Advertisements

PoC || GTFO

Posted in Hacker culture by anaumov on 31.07.2018

Давно хотел написать пару строк об этом журнале, но все руки не доходили довести пост до состояния, когда его наконец уже можно опубликовать. В прошлом месяце вышел очередной его выпуск, но из-за смены работы у меня снова не дошли руки. Среди security-инженеров так же бытует мнение, что это не то издание, о котором стоит рассказывать “широким массам”. Спорный момент. Так или иначе No Starch Press выпустила печатное издание всех номеров журнала.

Итак, для тех, кто слышыт об этом журнале впервые, International Journal of Proof-of-Concept or Get The Fuck Out или просто PoC || GTFO представляет из себя интернет-журнал для технарей, любителей поиграться с ЭВМ, чья осведомленность принципами работы последнего не должна вызывать никаких сомнений, ребят, в конец отбившихся от рук и, как правило, стоящих на учете в соответствующих огранах… одним словом – сетевых, тьфууу, хулиганов.
А теперь серьезно – этот материал будет немного покрепче 2600 или Phrack. Материал, публикуемый там, называют “научными публикациями” той же тематики. Там не учат ни С, ни ассемблеру, ни основам микроэлектронники, ни скользким моментам различных поведений программ на разных платформах, где работа типов процессоров отличается – все это надо иметь при себе.

Спектр тем включает в себя computer science, intellectual challenge, hacker culture, reverse engineering, микропроцессоры и микроэлектронику вообще (доходит до химии (да, надо сказать методы, к которым прибегают авторы для достижения описываемых целей, очень и очень креативны)), эксплойды… кстати, в отличие от многих других изданий, там не просто публикуются все новые и новые эксплойды с коротким описанием, словно в новостной ленте, но подробное описание принципов, нарушение которых и привели к ошибке и легли в основу эксплойда. Подробно описывается сам процесс анализа, да и вообще причин, из-за которых этот анализ проводили. Издание учит учиться. И мыслить шире. Порой складывается впечатление, что авторы специально выбирают нетипичные методы взлома, если процесс от этого станет интереснее. Объективности ради надо сказать, что не все темы связаны с security, но безусловно все – с красотой процесса и творческим подходом к решению задачи, оценить которые, как оно обычно и бывает в разных областях искусства, смогут далеко не все.

Leap 15.0 Beta testing: Fujitsu U757 Laptop

Posted in Linux Kernel, SuSE [ru] by anaumov on 25.05.2018

2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.

Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:

# rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…

Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.

Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч был принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.

После установки этого ядра libinput отлавливает events:

# libinput debug-events

 -event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) pressed
  event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) released

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

Удачи! Have a lot of fun =)

The Linux Programming Interface: Russian edition

Posted in books, GNU/Linux by anaumov on 23.03.2018

LPIbookСлучайно заметил в одном из российских интернет-магазинов перевод The Linux Programming Interface Майкла Керриска. Не удержался и сразу же заказал его 🙂
Русское издание по качеству практически не отличается от оригинала. Я уверен, что многие это оценят.
Про английскую версию я писал ранее.
Книга очень классная; пожалуй одна из лучших в моей библиотеке по системному программированию в GNU/Linux (подробно описывается работа с библиотечными функциями/вызовами, нюансы работы с памятью, shared libraries, несколько последних глав посвящены в том числе и сетевому программированию… и многое и многое другое). Книга содержит множество продуманных полнофункциональных программ, доступно иллюстрирующих все теретические концепции и будет очень полезна тем, кто уже хорошо знает язык С и хочет плотнее поработать с операционной системой.
Англоязычное издание этой книги вышло почти 7 лет назад. С тех пор kernel да и glibc претерпели немало изменений. Тем не менее, актуальность материал не утратил. Потому что во-первых, интерфейс API остается практически неизменным, т.е. разработчики его меняют очень осторожно. Причина тому – совместимость программ в userland с новыми версиями glibs и kernel. Во-вторых, изменения вносятся лишь в виде дополнений, но не как не изменений поведения и модификаций уже существующих интерфейсов. Кстати, для тех, кому интересно – вот тут можно посмотреть как менялись API от версии к версии. Занятное чтиво для ботанов %)

Leap 15.0 Beta testing: configuring 802.1x (auth with RADIUS)

Posted in Network, security, SuSE [ru] by anaumov on 15.03.2018

В этом посте я попытаюсь рассказать как настроить IEEE 802.1x в openSUSE. Сейчас Leap 15.0 в активной стадии бета-тестирования, поэтому возьмем её и для клиента и для сервера, чтобы убедиться, что все работает как надо, и никаких неприятных сюрпризов в финально-официальном релизе нам ждать не придется.

Если в двух словах, 802.1x это стандарт сетевой аутентификации. Работает на втором OSI уровне и определяет механизм контроля доступа к сети на основе принадлежности к порту и проверки x509-сертификатов. Доступ к сети получают только клиенты прошедшие аутентификацию. В качестве “системы, проверяющей подлинность” или просто аутентификатора я буду использовать CISCO SG300-28 28-Port Gigabit Managed Switch. Для проверки он будет обмениваться сертификатами с authentication server, который мы попытаемся развернуть на отдельной машине и который будет колдовать для нас x509 TLS-сертификаты.

Authentication server

Когда я только задумывал этот пост, я представлял это себе как “пустяковое дело на 20 минут”. Сразу же после установки я понял, что “приключение начинается”. Инсталлер разучился отключать firewall и включать OpenSSH. Фича? Аха щас… BUG! Первый баг. Попался 🙂 Пытался сначала достучаться до людей в IRC, все бестолку. Три дня думал, что я что-то пропустил и искал информацию. Так ничего и не найдя, я заглянул в ML, где меня ждал успех.

Очень не приятно после установки заходить в систему и отключать firewalld и включать sshd… но на сейчашний момент это именно то, что мы имеем:

# systemctl stop firewalld
# systemctl disable firewalld
# systemctl start sshd
# systemctl enable sshd

Напомню, что мы тут просто тестируем 802.1x. На практике отключать firewall конечно же не обязательно, достаточно открыть UDP/1812 и UDP/1813 порты.

Приступаем к установке authentication server. Мы будем использовать freeradius. Последняя стабильная версия – 3.0.16 – вышла два месяца назад. В openSUSE пакет называется freeradius-server. Устанавливаем его:

> sudo zypper in freeradius-server
> rpm -qa freeradius-server
freeradius-server-3.0.16-lp150.1.3.x86_64

После установки переходим в /etc/raddb/certs. Тут все будем делать от root.

# ll /etc/raddb/certs
total 48
-rw-r----- 1 root radiusd 6155 Feb 20 06:18 Makefile
-rw-r----- 1 root radiusd 8714 Feb 20 06:18 README
-rwxr-x--- 1 root radiusd 2706 Feb 20 06:18 bootstrap
-rw-r----- 1 root radiusd 1432 Feb 20 06:18 ca.cnf
-rw-r----- 1 root radiusd 1103 Feb 20 06:18 client.cnf
-rw-r----- 1 root radiusd 1131 Feb 20 06:18 inner-server.cnf
-rw-r--r-- 1 root radiusd  166 Feb 20 06:18 passwords.mk
-rw-r----- 1 root radiusd 1125 Feb 20 06:18 server.cnf
-rw-r----- 1 root radiusd  708 Feb 20 06:18 xpextensions

Документация о том, как сгенерировать сертификаты (самый минимум) находится в файле README. 3 шага: генерация root-сертификата (ca.pem), генерация сертификата сервера (server.pem) и клиента (client.pem). Необходимые параметры нужно указать в конфиг файлах: ca.cnf, server.cnf и client.cnf соответственно.

Несмотря на то, что все кажется простым и логичным, генерация TLS/SSL сертификатов может быть оказаться достаточно запарным процессом. Особенно если вы нечасто этим занимаетесь. Дело в том, что сообщения об ошибках не всегда понятны. Давайте рассмотрим пару примеров.

Во-первых, нигде не сказано, что пароль в /etc/raddb/certs/server.cnf и /etc/raddb/mods-enabled/eap должен быть один и тот же. Вот в этом месте файла /etc/raddb/mods-enabled/eap надо быть осторожней:

        tls-config tls-common {
                private_key_password = myTEST1eap
                private_key_file = ${certdir}/server.pem

Вот так выглядит часть /etc/raddb/certs/server.cnf файла, где нужно быть чуточку внимательней:

[ req ]
prompt                  = no
distinguished_name      = certificate_authority
default_bits            = 2048
input_password          = myTEST1eap
output_password         = myTEST1eap
x509_extensions         = v3_ca

Если пароли окажутся разными, то при запуске cервера мы получим в логах вот это:

Wed Mar  7 17:08:15 2018 : Info: Debugger not attached
Wed Mar  7 17:08:15 2018 : Error: tls: Failed reading private key file "/etc/raddb/certs/server.pem"
Wed Mar  7 17:08:15 2018 : Error: tls: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
Wed Mar  7 17:08:15 2018 : Error: tls: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error
Wed Mar  7 17:08:15 2018 : Error: tls: error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt
error
Wed Mar  7 17:08:15 2018 : Error: tls: error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib
Wed Mar  7 17:08:15 2018 : Error: tls: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
Wed Mar  7 17:08:15 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 17:08:15 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 17:08:15 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Согласитесь, с ходу не ясно в чем тут может быть проблема.
Остальные пароли могут быть (должны быть) разными.

Во-вторых, можно забыть про команду:

# openssl dhparam -out dh 2048

В bootstrap скрипте она есть, но если вы решите сгенерировать сертификаты дважды и отчистите все командой

# make destroycerts

то make удалит и файл /etc/raddb/certs/dh, а при make ca.pem или make server.pem файл dh снова создан не будет. При запуске сервера это приведет к следующему сообщению в логах:

Wed Mar  7 16:18:44 2018 : Info: Debugger not attached
Wed Mar  7 16:18:44 2018 : Error: Unable to check file "/etc/raddb/certs/dh": No such file or directory
Wed Mar  7 16:18:44 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 16:18:44 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 16:18:44 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Обратите внимание, что в README файле написано, что удалять старые сертификаты нужно вот так:

# rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*

т.е. без dh файла. Это, пожалуй, единственная проблема, суть которой ясна из сообщения об ошибке.

И вот еще одина проблема, с которой, я надеюсь, никому не придется столкнуться:

failed to update database
TXT_DB error number 2

Она возникает по причине того, что CN (Common Name) для генерируемого сертификата такое же как и для CA-сертификата.

Последний шаг настройки RADIUS – прописываем имя, ip и secret клиента (остальное можно оставить как есть) в /etc/raddb/clients.conf. Клиент в данном случае – наш cisco-коммутатор. Шаг простой, но очень важный. Без него RADIUS не будет отвечать коммутатору. Secret тут должен быть как можно сложнее.

После того как все сертификаты созданы, для уверености их можно сверить:

# openssl verify -CAfile ca.pem client.crt client.pem
client.crt: OK
client.pem: OK

Если все в порядке, запускаем сервер, проверяем созданные им сокеты:

# systemctl start radiusd

# lsof -i :1812
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
radiusd 4811 root    7u  IPv4 179990      0t0  UDP *:radius 
radiusd 4811 root    9u  IPv6 179994      0t0  UDP *:radius 

# lsof -i :1813
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
radiusd 4811 root    8u  IPv4 179993      0t0  UDP *:radius-acct 
radiusd 4811 root   10u  IPv6 179995      0t0  UDP *:radius-acct

# tcpdump -vv -n -i eth0 -S port 1812 -l -A -X

Последняя команда может помочь при отладке. Вы видете, что именно ушло в сеть. Даже если вы подробно не знакомы с EAP, можно заметить отличие удачных попыток авторизации и не очень удачных 🙂 Если по той или иной причине возникли проблемы, log radius-сервера находится в /var/log/radius/radius.log.
Если все же возникнет какая-то новая проблема, которая тут не описана, и вы начнете искать информацию в инете и найдете примеры программы radtest(1) и попытаетесь ее запусить… в openSUSE она лежит в отдельном пакете:

> rpm -qf $(which radtest) 
freeradius-server-utils-3.0.16-lp150.1.3.x86_64

Я не стал описывать ВСЕ, что мне пришлось пережить за эти пару дней… и так этот пост разбух и стал походить на статью. Возможно я напишу еще что-то о самой openssl в отдельной статье. Тема PKI очень интересная и нужная. Ее понимание требуют многие работадатели.

Но вернемся к нашему тестированию. Переходим к настройке нашего коммутатора. Пока новых жуков не обнаружено 🙂

Authenticator

Настройка аутентификатора (или “системы, проверяющей подлинность”) сводится к простому добавлению в список RADIUS-серверов только что настроенной машины. Security => RADIUS => Add:

В появившемся окне просто добавляем IP-адрес и secret, который мы указывали /etc/raddb/clients.conf на RADIUS-сервере. Secret – это фактически единственный механизм аутентификации между cisco-коммутатором и сервером проверки подлинности (RADIUS). Эта часть сети в 802.1x-схеме подразумевает достаточно доверительные отношения между хостами, т.е. остается практически не защищенной. Поэтому повторюсь – secret должен быть как можно сложнее.

Client

Переходим к последнему шагу – настройке клиента.
Да, друзья мои, в качестве клиента openSUSE сейчас использовать увы, не получится. Для тестирования 802.1x мне пришлось взять какой-то другой GNU-дистрибутив. Но обо всем по порядку.

Сначала я поставил Leap 15.0 Beta с Plasma 5.12 LTS. networkmanagement отказался создавать соединение, и я сначала подумал, что проблема в созданных мной сертификатах. Я потратил несколько дней на проверку и перегенерацию сертификатов. Я устанавливал Leap с GNOME… с Xfce… и вообще без X. Паралельно я проверял все в Tumbleweed, и это меня и сбило с толку. Там соединение тоже не работало и я подумал, что проблема на 8 OSI уровне 🙂
Через несколько дней я попробовал другие GNU-дистрибутивы и оказалось, что, используя те же самые сертификаты и конфиги, там соеднинение удается создать одной командой…

BUUUUG! Да, черт побери, и сидит он так глубоко, что ни одним NM-апплетом его не достать. Он воспроизводится и через nmcli(1):

# cat /etc/NetworkManager/system-connections/LEAP_8021x
[connection]
id=LEAP_8021x
uuid=de2f2a7c-33cc-4d92-ae3b-785575dffddc
type=ethernet
permissions=user:alex:;

[ethernet]
auto-negotiate=true
mac-address-blacklist=

[802-1x]
ca-cert=/home/alex/ca.pem
client-cert=/home/alex/client.crt
eap=tls;
identity=GNOME
private-key=/home/alex/client.pem
private-key-password=GNOME

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

# nmcli con reload

# nmcli con up LEAP_8021x
Secrets are required to access the wired network 'LEAP_8021x'
Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli
cannot ask without '--ask' option.
Error: Connection activation failed: Secrets were required, but not provided

Secret я использую и в конфиге и прописывал его и в апплетах GNOME и KDE. Не принимает ни в какую.
Пробовал испльзовать ‘–ask’, результат тот же: спашивает, вводишь пароль… снова спрашивает, снова вводишь… снова спрашивает…

# nmcli con up LEAP_8021x --ask
Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****
Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****

Я использовал и wpa_supplicant(1). Результат такой же. Он просто повисает.

Чтобы довести дело до конца я взял Kubuntu 17.10. Выбор был не случайным, т.е. это не был “первый дистрибутив, который попался под руку”. Пока я искал инфу по поводу проблем с 802.1x, я нашел этот BUG. Я не уверен, что это именно то, но повеселил меня не тот факт, что проблема в upstream’е, а то, КАК это решили в Ubuntu 🙂 Ребятами из RedHat (хотя там ссылка на GNOME, а оттуда на Debian…) было предложено и другое решение. Следить за изменениями я уже не стал. Хотя разобраться до конца все же стоило бы.

В Kubuntu 17.10 просто кидаешь конфиг в /etc/NetworkManager/system-connections/802.1x и перезапускаешь сеть (без ‘–ask’), как я показал выше. Понадобятся 3 сертификата: клиентские сертификаты client.pem и client.crt (к ним надо знать secret) и root-сертификат CA.pem. При генерировании новых клиентских сертификатов нужно лишь обновить client.cnf (имя и secret) и сделать

# make client.pem

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

Итак, ситуация Leap 15.0 пока очень и очень не классная. BUG’ов в beta хватает. О них знают, и можете быть уверенными, друзья мои, их исправят.
Оставайтесь на светлой стороне. И да прибудет с вами удовольствие от работы с openSUSE 🙂

openSUSE Leap 15.0: call for testers

Posted in SuSE [ru] by anaumov on 23.02.2018

Самый разгар тестирования следующей major-версии openSUSE – Leap 15.0. Beta доступна уже без малого месяц. Как и обычно, качество системы зависит от нас с вами, друзья. Для тех, кто никогда не принимал участия в разработке openSUSE, но хотел бы наконец-то помочь, самое время скачать Leap 15.0, установить и погонять его по самые не балуй 🙂 на своей машине (хотя бы виртуальной) или машине своего коллеги 😀 Помните, что beta-версия нестабильна и может сломаться в самом непредсказуемом месте.
О всех найденных ошибках надо сообщить нам в bugzilla.

Важно понимать, что система разрабатывается силами сообщества, и ее качество в большей мере зависит он нас с вами. Ошибается тот, кто думает, что в Нюрнберге все и так сделают как надо и даже лучше. Там ребята работают главным образом над SLE – тем, что приносит SUSE деньги. Дистрибутив openSUSE отдан сообществу: энтузиастам, дизайнерам, программистам… и простым пользователям. У нас есть права менять его как мы захотим. Более того – от нас этого ожидают. Не будем же делать вид, что это не так.

Итак, что мы имеем на сейчашний момент? На момент написания этого поста актуальным является build139. Второй и третьей официальной beta, как это было когда-то, не будет. Теперь beta меняется по принципу rolling release. Уже где-то через месяц, в апреле/мае, мы перейдем на фазу release candidate. Было бы здорово найти как можно больше и начать работать над исправлениями ДО начала этой фазы.
Так как следующий Leap получится мажором, поддерживаться он будет не 12 (в отличии от минорных релизов, привязанных к SUSE Linux Enterprise Service Packs), а 36 месяцев.

Так что же собственно тестировать? Для каждого из нас есть свои use cases. Кто-то админит самый обычный web- и mail-сервер, кто-то не может представить свою жизнь без какой-то хитроумной конфигурации Kerberos, кто-то в Leap видит исключительно desktop-систему и захочет посмотреть на сколько стабильна в ней работает Plasma 5.12 LTS. Я, к примеру, планирую протестировать sddm c PAM, а так же freeradius сервер со своим 802.1x L3-свитчем. Также будет интересно посмотреть, получится ли обновить свой Leap до нового Leap 15.0.
Кстати, в Leap 15.0 используется новый rpm из Tumbleweed – версии 4.14.1 (с целым вагоном и маленькой тялежкой SUSE-патчей). Возможно там получится что-то найти.

Я оставлю ссылку на эту таблицу. Туда вы можете добавить себя и добавить комментарий, если что-то сломано и не заработало (если заработало, тоже можете оставить комментарий). Помните только, что если что-то не заработало, и вы написали там об этом, мы будем ожидать, что вы откроете report в bugzilla, где и будет проходить дальнейшее обсуждение проблемы.
Возможно вам будет также интересно узнать о состоянии автотестирования.

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

Если у вас возникли вопросы, я всегда буду рад помочь вам. Оставляйте комментарии или просто пишите на alexander_naumov @openSUSE.org. Меня так же можно найти на freenode IRC-сервере. Мой ник там – anaumov. Удачи!

FOSDEM 2K18

Posted in Events, GNU/Linux, openSUSE by anaumov on 08.02.2018

The Free Open Source Developers European Meeting (FOSDEM) 2018 happened over the weekend. FOSDEM is a fantastic conference where Free Software enthusiasts from all over Europe can meet together at once a year (more than 17000 MAC addresses were registered this time). I really like its clearly unique atmosphere. As usual, 2 amazing days in Brussels, Belgium…

The reason why I visit it again and again. It charges you. When you see all these developers, visit these talks/presentations, have so many conversation with contributors, get innovation ideas that are shared there. It motivates you to get a copy of The Linux Programming Interface & TCP/IP Guide and hack away your amazing Linux software 🙂
Most of the talks were recorded. That’s nice, but by watching it online you just get information, by visiting these talks in person and taking part in discussions, you get much much more.

This time I was there together with my LiMux colleagues from Landeshauptstadt München. By the way, as you maybe know, we’re going to share as much as we can until Munich migrates to Windows (unfortunately, because of bureaucratic reasons making software freely (share it) sometimes is not so easy as we want).

Like in last year FOSDEM was held in so-called “developer rooms”. First I planned to visit devrooms such as debugging tools, DNS/DNSSEC and security + encryption. That was my target when I planned my program. But as I noticed later I was not the only one who had the same plans to visit the same talks, hacking sessions and open discussions 🙂 That led to the free-places-problem in the devrooms and it made my program a bit more dynamic than I planned first 🙂 But get it right – that was absolutely no problem for me. Outside we also had very interesting conversations. I met ex-colleges, friends whom I knew from mailing lists and IRC only and of course a lot of openSUSE contributers.

I would like to thank FOSDEM’s staff, everyone who made it happen, who helped to organize it (I’m definitely going to send a feedback to you guys). Thanks GitHub for free coffee. Keep it going 🙂 I also have to say thanks for openSUSE’s Travel Support Program. It supports me to visit this amazing event (and not for the first time!). I’m going to visit FOSDEM again next year. My photos can be found here. See you next time 😉

Good idea %)

Posted in security by anaumov on 26.01.2018

pam-accesscontrol: PAM-based access control system written in python

Posted in python, Qt, security by anaumov on 27.12.2017

In traditional UNIX/Linux authentication there is not much granularity available in limiting a user’s ability to login. For example, how would you limit the number of users from a specific group? What if you want to allow some users to log in from a specific host, but disallow all others from a same host? Firewall can not help at this point. What if you want to allow SSH for someone, but not X- or login sessions on tty? And… what if you want to be able to decide about allowing SSH-session for someone at the same moment when connection will be established?

PAM, or pluggable authentication modules, allows for you just this sort of functionality (and more) without the need to patch all your services. PAM is flexible enough to provide solution for all of the above listed issues. All what you need at this point is just implement a new PAM-plugin for your needs.

Some times ago I came across pam_python — a PAM module that lets you write PAM modules in python. During paying with pam-python I implemented my own plugin as a hobby. At the beginning that was just notification window about every new incoming SSH connection. After that I added possibility to allow or denied every new established SSH connection by asking the owner of the X session (that was implemented just for desktop users in mind, of course). Next – define the list of users who may to login any time, who should wait for confirmation and who should never get the shell on my machine. I came on idea to put these lists to the config file. Project grew quickly. Now I would like to introduce it, show the sources and invite everyone (who love coding) to take a part of the development 😉

Introducing

I called it pam-accesscontrol. Before we start I would like to remind you, that it was implemented as a hobby project just for fun and it’s still unstable, i.e. can broke something on your system. “Someting” is, for example, possibility to login via tty/login(1), SSH or display manager . So, you can just look at the source code or, if you really know what you’re doing, install the package.

To be able to understand how PAM and pam-accesscontrol communicate with other, take a look at doc-page where you can find the list of pam-python methods which are nothing other then a interface for Linux PAM APIs. Every PAM event like open_session, close_session, authenticate, etc. will call appropriate pam-python method. This method will call appropriate pam-accesscontrol function.
For example, OpenSSH: by using password authentication procedure PAM calls pam_authenticate function, which call pam-python’s pam_sm_authenticate function. You just need to implement pam_sm_authenticate-method in your plugin to intercept further steps in the authentication process. Pam-python is just a “bridge” between PAM and pam-accesscontrol:

As you can see, we also should tell PAM (add configuration to files in /etc/pam.d/ directory) to call plugin in some necessary cases. Necessary cases are services like, for example, sshd or login (depend on our wishes) and events like auth, session, etc.

List of all available PAM modules can be found in /lib/$(arch)-linux-gnu/security/ directory. After installiing pam-python package pam-python.so file should be there and after installing pam-accesscontrol package — accesscontrol.py script.

/etc/pam-accesscontrol.d/pam-accesscontrol.conf

PAM-accesscontrol’s behavior depend on its config file. You add rules for /etc/pam.d/* services like sddm or login. It’s similar to iptables rules: by an authenticate new user or creating new session, pam-accesscontrol will read config file, parse it and try to make a decision. Actually, pam-accessconfig is nothing else then just a parser. It’s possible to close access for everybody and specify in what case and for whem it will be open, or vice versa — just define who should have no access. At the end, decision has made by pam-accesscontrol will be returned to PAM.

Right after package installing it has just one rule in its config file: DEFAULT:OPEN, i.e. access open for everyone. If this DEFAULT variable will be not set in config file, pam-accesscontrol initialize it with CLOSE value.

Let me show some configuration examples.

> cat /etc/pam-accesscontrol/pam-accesscontrol.conf

DEFAULT:CLOSE
sshd OPEN GROUP lp,users
sddm OPEN USER bob,alice
login OPEN USER bob,alice

First line of this configuration closes access for all users. After that we open SSH (password authentication) for all users from lp and users groups (it supports LDAP groups, POSIX groups and primary user groups); open access via sddm for users bob and alice; open access via login for users bob and alice. Pretty easy. Every rule should have exactly 4 fields. If rule is broken, it will be just ignored.

It’s possible to set limit for number of users from specific group.

sshd NUMBER GROUP users:2,lp:3

For example, this line sets limit to 2 for group users and to 3 for group lp. In other words, new SSH connection will be possible for users from group lp, if only 2 or less users will be logged on this system at the same time.

It’s also possible to configure it so that it will ask you for every new incoming connection. With this line in config file everyone from group lp will wait for your confirmation:

sshd-key ask group operation

It means, access will be granted via SSH by using public-key authentication only for someone from group operation… only if X-session owner allow it.

It calls QMessageBox from PyQt5 that returns 0 or 1 to pam-accesscontrol depend on your choice. This value will be interpreted as allow or not allow. By the way, if there is no active Xorg session, pam-accesscontrol will not be able to ask you… so in this case this will be interpreted as an OPEN rule. Also keep in mind that pam-accesscontrol ask owner of the Xorg session only for the first SSH incoming connection. Remote user would like, for example, to copy 100 files on its host; in that case also just one confirmation at the begging will be needed.

74975662

X-session owner also will be informed when remote user (whose SSH session was confirmed through QMessageBox) ends its SSH session.

Debugging

Pam-accesscontrol uses syslog. It creates logs after every successful authentication. As usual, on systemd-based systems you can use journalctl(1). Also some logs can be found in /var/log/auth.log (authentication phase) and /var/log/syslog files. By default, there is not so much information. For debugging and during development it’s a good idea to enable debug/verbose mode. Add debug:true to the config file and it will put much more info about why it made this or that decision.
It also creates its own logfile /var/log/pam-accesscontrol-YEAR-MON.log where is stored short statistic about when, who, via which interface tried to login and also — was it successful or not.

Use ldd(1) to check PAM compatibility for supported interfaces:

# ldd $(which sshd) | grep pam
        libpam.so.0 => /lib64/libpam.so.0 (0x00007f82cdfff000)
# ldd $(which login) | grep pam
        libpam.so.0 => /lib64/libpam.so.0 (0x00007fee7f3c9000)
        libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007fee7f1c5000)

 

Google Cloud Summit 2017, Munich

Posted in cloud, Events by anaumov on 12.12.2017

OnBoard meeting at Google on 20 November sparked interest in me in Google Cloud Platform. After this event, having considered that again and collecting everything together at home, I got some new questions about this platform. That was not only technical questions. That was interesting to know about plans for developing, what developers think about its platform itself, how they compare GCP with Amazon Web Services and Microsoft Azure in general, what customers think about it and why they move its data to GCP, how secure is it, and how can I be sure that my data in the cloud will not be analyzed, and what happened if, for example, some employee upload some personal confidential data by mistake. There are a lot of questions, actually. Google Cloud Summit 2017 in Munich was organized exactly to answer on these.

All presentations were spited into four parallel sets. Thus, you could better orient yourself and could know better what to expect from this or that talk/presentation. Technical talks include not only HOWTOs about integration your infrastructure with an Google Cloud, but also how exactly “under the hood” components communicate with other. GCP includes few Free Software components like Docker and Kubernetes, so talks about there components, where Google shared its experience, attracted a lot of attention of DevOps people.


There was few places where you could ask Google developers about technical things like architecture in general or compatibility with some extra components or, for example, does Google has some plans to open the source code for GCP? 😉
By the way, with this topic – opening the source code for everybody, I got the luck – I met there one developer who spend some time to develop OpenStack in the past. He explained about some problems with OpenStack like, for example, maximum limits for amount of instances (VMs) deployed at same time, that GPC doesn’t have. I don’t want to put technical details here, but I’m going to test it. Unfortunately, that’s not so easy to play with cloud at home 🙂 It needs at least small datacenter if you want to test such things like maximum capacity, how scalable is it, how easy you can scalable it, etc. But if we’re talking about GCP, we will need not just a datacenter, but Google’s datacenter… Yes, unlike OpenStack, GCP is a proprietary software – it’s not available for downloading at all. Again, Google and its customers doesn’t see that as a problem: Microsoft Azure and Amazon Web Services also proprietary, so what?

There were also few stands where Google’s employees share information about specific topics like Google training program, GCP and bigdata, etc. I spent some time to inform myself about possibilities to prepare and take the exam and get certificate in Munich. Cloud is a very sexy topic today and it’s not just interesting, but I guess to have Google certificates can be very useful in case you can find new good employer.

As a conclusion I would like to thank Google for a very good organization summit. I also would like to see more Open Source components in GCP. This is my wish. In my opinion this will be a big-improving-quality-step.
Thanks again and see you next time 😉

Google Cloud Platform: OnBoard training in Munich

Posted in cloud, Events by anaumov on 22.11.2017

Yesterday Google invited everyone who is interested in cloud technology to its office in Munich. Cloud OnBoard is a free, full-day training event, where Google introduces its “Google Cloud Platform”. Well… what can I say… That was amazing. Well organized, well presented. I love it. I never worked with GCP before. This event included not only in-depth technical presentations about every part of the platform, but also demonstrations, examples, questions and exercises for participants.

Google Cloud Platform includes not only typical cloud parts that has, for example, OpenStack, but also supports BigData components. Yes, it’s compatible with API of Hadoops ecosystem. That was a nice surprise for me. When I visited some Cloud or BigData events or workshops I asked myself all the time why these technology can’t be merged. I missed an easy way to add new nodes to the Hadoop-cluser that could to analyze installed already components and add needed components to the new node of the cluster automatically. That’s exactly where cloud used for. On another hand, that will be very useful to analyze data about existing cloud on the cluster and change/reconfigure a cloud if it’s needed automatically.

Some features are sill under development, but all what was presented is very impressive. Just one thing makes me sad: some components of the platform are proprietary software 🙂 It makes platform unusable to hack and learn it in depth at home… On the other hand, Google is trying to create community around an platform and open the source code of some components like gcloud or Google App Engine. Some technologies used inside an platform like Docker and Kubernetes are 100% Free Software.

At the end everybody got certificates. Thanks for that!

Google Cloud Platform training accelerates your understanding of and ability to use the Google Cloud Platform services. By the way, today OnBoard meeting find the place in Google’s office in Hamburg and in 2 weeks I’m going to Google Cloud Summit 2017 in Munich. See you there 😉

Google Wind… I miss you so much in Munich :)

Posted in humor by anaumov on 21.11.2017

General Data Protection Regulation: Microsoft Cloud and Azure Security Center

Posted in cloud, Events by anaumov on 19.10.2017

Остается все меньше времени до вструпления в силу закона о GDPR, принятого европейским парламентом в прошлом году. После 25 мая 2018 года каждая европейская компания обязана адаптировать свою it-инфраструктуру таким образом, чтобы она удовлетворяла директиве 95/46/EC. В ФРГ пиратская партия, Chaos Computer Club и другие активисты внимательно следят за поправками к закону, а также с его совместимостью с немецким Bundesdatenschutzgesetz.
На сегодняшний день проблема под названием Windows 10, без остановки собирающая мета-данные пользователей и отправляя их на сервера компании для последующего анализа, остается нерешенной. Проблему усугубляют cloud-решения, где доступ к персональным данным находится под еще меньшим контролем.

Контроль доступа к данным осложняется еще и тем фактом, что мета-данные пользователя далеко не всегда могут быть удалены по требованию владельца из-за юридической стороны вопроса. Некоторые из мета-данных используются государством для предоставления социальных льгот. К примеру, чтобы получать от государства пособия по состоянию здоровья, должен быть доступ к истории болезни. Многие льготы предоствляются только прошедьшим военную службу, процент налогов снижается, если вы состоите в браке, процент налогов снижается еще раз, если у вас есть дети и т.д. Все эти данные принадлежат владельну, но, получается, так или иначе должны быть предоставленны государству. Или другой пример – информация о вас в базе данных у врача, к примеру, зубного врача. Как часто вы к нему приходили, что именно лечили, сколько за это платили, информация об аллергических реакциях и т.д. Если вы решите сменить врача, данные должны быть переданы дальше, т.е. они во-первых, они должны быть в таком формате, чтобы следующий врач смог ими воспользоваться, во-вторых, должно быть четко ясно какие именно данные должны быть переданы, а какие нет. Они защищены на уровне гос.законов, разглашение этой информации (любое, в том числе и случайное) будет наказываться огромными штрафами. Для Microsoft, к примеру, эта цифра составяет $ 3,598 миллиарда.

Тема использования Microsoft Cloud и Azure Security Center особенно актуальна сейчас в Мюнхене. На протяжении последних 15 лет данные жителей этого города хранились в Free Software базах данных, работающих на GNU/Linux. LiMux стал известен на весь мир как один из самых успешних проектов по переходу гос.учреждений на свободное ПО. До сих пор LiMux установлен на более чем 18 000 рабочих мест в столице Баварии. В начале этого года, несмотря на опубликованные Сноуденом документы и полную неспособность противостоять таким проблемам как, к примеру, WannaCry и Petya, было объявлено о планах миграции на продукты от Microsoft.

Вчера Microsoft пригласила всех желающих в свой офис и рассказала о планах интеграции своей cloud-платформы с GDPR и путях решения некоторых возникающих при этом проблем. Была продемонстрированы настройки и новые функции Azure Security Center. Многим текущее состояние показалось неудовлетворительным, а добавленные функции неудобными. Это при том, что конфигурация облака была специально спроектированна для демонстрации. Например, в мониторинг-системе, если текущее состояние VM не соответствует критериям настроек, нельзя быстро узнать что именно не так. Нельзя запрограммировать реакцию на то или иное событие. Нас уверили, что все проблемы будут устранены. Попросили создать аккаунты и отправить features request 🙂

Я благодарен за приглашение и информацию, которую я получил на этой встрече. Понимание cload-технологий, а также проблем, связанных с той или иной её реализацией, становится все важнее и важнее, и не только для it-инженеров (слайды: Accelerate GDPR compliance with the Microsoft Cloud и Azure Security Center in the context of GDPR _Partl_181017) Надеюсь, что Microsoft улучшит состояние своей платформы, и к маю следующего нам не придется переживать за наши данные 😉

openSUSE Conference 2017

Posted in Events, SuSE [ru] by anaumov on 27.06.2017

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


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

На конференции я снова встретился с Дмитрием, занимающимся проектом invis и продвижением Free Software решений на базе 1C в Германии. Беседовали о русскоязычном сообществе openSUSE, и о причинах его столь плачевного состояния. Я очень надеюсь, что сообществу получится преодалеть существующие проблемы и оно снова возьмет курс на развитие, как было в 2008-2010 годах.

Познакомился с Денисом Кондратенко из Киева и его женой. Очень приятная пара. Денис рассказывал о Ceph и EKG в openSUSE, а также о методах обработки метаданных в Elasticsearch. Мой личный опыт использования Elasticsearch ограничивается только BigData/Hadoop, поэтому и тут удалось узнать что-то новое.

Много новых иновационных идей было услышано от Ричарда. Он уже давно стал openSUSE evangelist’ом; его доклады об OBS или openQA можно услышать практически на каждой европейской Free Software конференции, посвященной GNU/Linux. Я всем советую посмотреть его доклад о Containerised Application.


Одним из спонсоров конференции в этом году стал fedora project. Fedora уже не первый год использует нашу систему openQA для автоматического тестирования linux-систем, а сотрудники RedHat уже во второй раз читают свои доклады на openSUSE Conference. В этом году это был доклад How semantic analysis of C and C++ ELF binaries can be used to analyze ABI changes, в прошлом году это были Enforcement of a system-wide crypto policy и Testing complex software in CI.

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

pam-python is avaliable for openSUSE

Posted in openSUSE, python, security by anaumov on 21.04.2017

Last week I came across pam_python, a PAM module that lets you write PAM modules in Python. It seems interesting to play in this direction, but I had to install it manually. It seems that there was no official packages for openSUSE until now…

Yesterday I built version 1.0.6 for Tumbleweed. Please test it. It’s in our security repo. Feel free to send submit requests.

After installing it we will get /lib64/security/pam_python.so PAM modul. It’s just an interface between PAM and your own plugin (that you have to implement). To test it, you will need to add PATH of your plugin to the /etc/pam.d/login file (in case of getty-access test, for example), like described here.

This code can be used as an example. It will close access for all getty.

> cat /lib64/security/access.py

def pam_sm_authenticate(pamh, flags, argv):
  if str(pamh.service) == "login":
    return pamh.PAM_AUTH_ERR

You will also need to add this line to the /etc/pam.d/login file:

auth required pam_python.so access.py

This is just an example with login service or getty. Pam-python supports also, for example, ssh- and kdm-services. It supports many other interesting things. For more info look at documentation page.