Введение

Протокол Kerberos 5 сейчас активно используется для аутентификации. Особенностью данного протокола является то, что он осуществляет аутентификацию, базируясь на четырех китах:

1. Симметричное шифрование;
2. Хеширование;
3. ЭЦП;
4. Третья доверенная сторона.

Начиная с пятой версии появилась возможность использовать еще асимметричное шифрование (для электронной подписи). Более подробно на работе протокола Kerberos останавливаться не имеет смысла, ибо описание алгоритма можно посмотреть тут.

К сожалению, количество алгоритмов шифрования, хеширования и ЭЦП, которые использует данный протокол, не настолько велико, насколько хотелось бы, поэтому в данной статье я хочу показать, как добавить легко и просто собственные алгоритмы в реализацию данного протокола MIT'ом. Добавлять же мы будем наши отечественные алгоритмы: ГОСТ 28147-89 (aka Магма), ГОСТ Р 34.11-2012 (aka Стрибог) и ГОСТ Р 34.10-2012 (хотелось бы тоже иметь для него aka, но я не знаю:(). Готовое решение для данных алгоритмов можно его найти в моем репозитории. На стороне клиента мы будем использовать аппаратные реализации алгоритмов ГОСТ в Рутокене ЭЦП 2.0 и их программные реализации в engine GOST для openssl. Но самый безопасный вариант хранения ключей – когда они генерируются непосредственно на Рутокене и никогда не покидают его память во время криптографических операций. Для такого варианта работы потребуется rtengine.

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

1. Использовать готовый дистрибутив для вашего одноплатного компьютера(Armbian, Openwrt и т.д.)
2. Собрать и настроить свой дистрибутив с помощью систем сборок(Buildroot/Yocto и т.д.).
3. Использовать свою связку bootloader (u-boot) + ядро(kernel) + rootfs (busybox).

Если Вы уже давно пользуетесь операционной системой Linux и хоть немного разбираетесь в программировании, рано или поздно Вам может понадобиться собрать программу из исходного кода. Может быть, нужной программы не окажется в репозиториях дистрибутива. Или в этих репозиториях программа старой версии, а Вам нужна самая свежая. А может, Вы создали новую программу и хотите поделиться ей с другими пользователями.

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

Надеюсь, эта статья поможет быстрее разобраться со сборкой пакета RPM для Rosa Linux или для другого дистрибутива, использующего менеджер пакетов RPM (Mandriva, RedHat). Или хотя бы подскажет, где искать информацию.

Здесь я покажу, как создавать пакеты RPM на своём локальном компьютере, на простом примере. Будем собирать программу xkb-switch в операционной системе Rosa Linux. Исходники программы будем брать с GitHub.

Встроенные средства контроля ресурсов используемой оперативной памяти в приложении

Мы являемся УЦ «Имярек», у нас возникло затруднение с выпуском ЭП в формате pkcs#11 для ЕГАИС, портал не понимает ЭП в формате «Имярек» CSP, просим Вас помочь в данной проблеме.

Часть 1
Часть 2
Часть 3
Часть 4

В предыдущей части мы только окунули пальцы ног в воды namespace и при этом увидели, как это было просто — запустить процесс в изолированном UTS namespace. В этом посте мы осветим User namespace.

Среди прочих ресурсов, связанных с безопасностью, User namespaces изолирует идентификаторы пользователей и групп в системе. В этом посте мы сосредоточимся исключительно на ресурсах user и group ID (UID и GID соответственно), поскольку они играют фундаментальную роль в проведении проверок разрешений и других действий во всей системе, связанных с безопасностью.

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

Увидел публикацию о том, что PVS таки научился анализировать под Линуксами, и решил попробовать на своих проектах. И вот что из этого получилось.