⌨ Labor omnia vincit ☮

Gekaufte Journalisten, 2015

Posted in Germany by anaumov on 26.04.2018

Advertisements

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 just 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 ware 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 were shared there… it motivate 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 of the discussions, you take much much more.

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

Like in last year FOSDEM was held in so-called “developer rooms”. First I planed to visit devrooms such as debugging tools, DNS/DNSSEC and security + encryption. That was my target when I planed my program. But, as I noted later, I was far from 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 planed first 🙂 But get it right – that was absolutely no problem for me. Outside we had also very interesting conversations. I met ex-colleges, friends with I knew until now from mailing lists and IRC only and, of course, a lot openSUSE contributers.

I would like to thank FOSDEM’s staff, everyone who made it happen, who helped to organize it (I’m really going to send an feedback to you guys). Thanks GitHub for free coffee. Keep it’s going 🙂 I also have to say thanks for openSUSE’s Travel Support Program. It supports me to visit this amazing event (and not first time!). For sure I’m going to visit FOSDEM again in 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 will 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 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 nothing others as a possibility to login via tty/login(1), SSH and X (supported login managers: kdm, gdm, xdm, sddm, lightdm). 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.
Below you can see how will be configured PAM during pam-accesscontrol installation:

for i in "sddm" "login" "sshd" "lightdm" "xdm" "kdm" "gdm"; do
    if [ -f "/etc/pam.d/$i" ]; then
      echo ""
      echo "#PAM-ACCESSCONTROL configuration" >> "/etc/pam.d/$i"
      echo "auth        required     pam_python.so accesscontrol.py" >> "/etc/pam.d/$i"
      echo "session     required     pam_python.so accesscontrol.py" >> "/etc/pam.d/$i"
      echo \[DONE\] successfully configured: $i
    fi
done

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 SSH, XDM or TTY services. 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
SSH OPEN GROUP lp,users
XDM OPEN USER bob,alice
TTY OPEN USER bob,alice

First line of this configuration closes access for all users. After that we open SSH for all users from lp and users groups (it supports LDAP groups); open access to the host via login manager for users bob and alice; open access via getty for users bob and alice. Pretty easy. Every rule should have exactly 4 fields. If rule is wrong, it will be just ignored.

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

SSH 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 SSH connection. With this line in config file everyone from group lp will wait for your confirmation:

SSH ASK GROUP lp

It means

  1. user should to login via SSH (know password or has ssh-key)
  2. after that you should allow this connection

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.

Xorg 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 trying to login. 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 log file /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.

Silicon Valley

Posted in fun by anaumov on 29.03.2017


Can’t wait for the next season… 😉

GNU Screen v.4.5.0

Posted in GNU/Linux, openSUSE by anaumov on 18.01.2017

I’m proud to announce the release of GNU Screen v.4.5. This time it’s mostly a bugfix release. We added just one new feature: now it’s possible to specify logfile name by using parameter -L (default name stays screenlog.0). Myself also spent some time to make source code a bit cleaner.

As you probably noticed we were going to release 4.5 until Christmas. Unfortunately, we could not do it because of some internal GNU problems. I apologise for that.

As usual, we merged some community patches from our bug tracing system (small patches also were presented in IRC) and I would like to thank everyone who contribute to Screen and helps us to test development git-version!

For openSUSE users: I updated our devel-package already. It’s soon in factory and, as usual, after openQA routine new package will be available in Tumbleweed.