Comments 20
По-моему тут некий эмоциональный перегиб в сторону "максимальная безопасность нужна всем и во всех случаях". Это наверное не совсем правильно т.к. операционные системы вообще и дистрибутивы на базе Debian в частности используются в очень разнообразных условиях. Тут нет какой-то конкретики, прямо таки кейса "вот здесь сломали apparmor потому что это не selinux" и получается довольно туманно. Если речь идёт об ubuntu в подах кубернетеса например, в системе где безопасность обеспечивается снаружи - насколько это (туманное) различие между apparmor и selinux помешает?
09.07.2019 16:42 Официально завершена сделка о покупке Red Hat компанией IBM
https://www.opennet.ru/opennews/art.shtml?num=51063
08.12.2020 18:46 Red Hat прекращает разработку CentOS 8 в пользу тестового CentOS Stream
https://www.opennet.ru/opennews/art.shtml?num=54219
21.06.2023 17:50 CentOS Stream станет единственным публичным источником кода пакетов RHEL
https://www.opennet.ru/opennews/art.shtml?num=59323
30.08.2023 11:46 В ядре Linux убрали упоминание связи SELinux с АНБ
https://www.opennet.ru/opennews/art.shtml?num=59685
"...В кодовую базу, на основе которой будет сформирован выпуск ядра Linux 6.6.
Механизм SELinux был разработан АНБ, включён в состав ядра Linux в 2003 году и используется во многих дистрибутивах Linux.
Последние 20 проект развивается под крылом сообщества и сопровождается независимыми мэйнтейнерами.
Решено перейти на использование имени "SELinux" вместо "NSA SELinux"
в комментариях и документации в Kconfig (например, пояснение к сборочному параметру SECURITY_SELINUX изменено с "NSA SELinux Support" на "SELinux Support")..."
https://en.wikipedia.org/wiki/Security-Enhanced_Linux
"...SELinux has been implemented in Android since version 4.3. Other distributions include support: Debian 9 Stretch and Ubuntu 8.04 Hardy Heron..."
Нет проблем в использовании SELinux на Debian.
На Debian и Arch Linux уже несколько лет использую podman с buildah и skopeo.
Когда в конце мая 2024 заблокировали Docker Hub, я и не заметил. Настроено проксирование через mirror.gcr.io.
https://github.com/containers/podman/blob/main/test/registries.conf
Вам надо новостникам Хабра устраиваться, это они любят накидать в конце портянку новостей, хоть как-то относящихся к теме.
"...Ничего, мужчина может иметь безобидное хобби..."
Было интересно отследить метаморфозы Red Hat, Inc. после сделки с IBM.
Посмотреть, кто принимал участие в создании SELinux - NSA's Official SELinux Homepage
"...Debian недостаточно делает для защиты пользователей. Хотя AppArmor способен обеспечить надежную безопасность при правильной настройке, настройки Debian «из коробки» не используют весь его потенциал..."
ansible-debootstrap - отличная штука
Linux Security Modules (LSM) в ядрах от Debian дают возможность использовать альтернативы: SELinux, Tomoyo
https://wiki.debian.org/AppArmor/HowToUse
https://wiki.debian.org/SELinux/Setup
https://wiki.debian.org/Tomoyo
Возможно у меня плохой опыт. Но если на проекте, или в дальнейшей эксплуатации отсутствует персона безопасника, то SELINUX=disabled присутствует почти всегда.
Иногда для работы средств защиты тоже необходимо отключать SELinux:
довелось потрогать несколько крупных отечетсенных проектов (не буду тыкать пальцем, уж извините, хрен его знает, может под nda попаду) - и в одном точно (и еще в другом - кажется, но лень искать) на первых строках мануала - необходимо отключить selinux. и что любой безопасник с этим сделает? ну вот такое вот треботвание у внедряемого софта...
и да, это не про средства защиты
Статья-то переводная. Реальный автор не знает про "отечественные" проекты ))
Ну а что, может, кто из сотрудников "отечественных" проектов напишет контр-статью, где поделится, почему они делают так, как делают. Ну, что на selinux свет не сошёлся, и что в трудное время выбор между "шашечки" или "ехать" нужно делать в сторону высокой цены быстрейшего запуска?
статья - да. но отвечал на первый комментарий в этой ветке Vengberga. вернее, дополнял
А кто, кроме безопасника будет следить за безопасностью? Кому платят, тот и делает.
В базовой конфигурации не должно быть явных уязвимостей, вроде СУБД без пароля на адресе 0.0.0.0. Больше ничего от хорошего дистрибутива не требуется.
Что сильно дискредитирует Debian, так это wiki.debian.org, местами сильно устаревшая и несогласованная. На фоне ArchWiki и docs.redhat.com очень уж бледно смотрится.
вторичных сборок RHEL
Oracle Linux
Это Вы сейчас накидываете на вентилятор?
В голосовании не нашел "Иное мнение". Что значит безопасность? Это наверно когда безопасно? А как безопасно? Совсем или что-то не безопасно? ... Во первых RH коммерческий дистрибутив и они хороши в этом "точка". Поэтому из коробки у них SELinux и уже в enforced. Дистрибутив Debian это другое (https://www.debian.org/intro/why_debian#:~:text=Debian is made of free,It's also free of cost.) и он довольно не плохо поддерживается. Ничего не мешает в Debian установить пакет политики по умолчанию в stable дистрибутиве (selinux-default-policy) и выключить модуль unconfined (https://debian-handbook.info/browse/stable/sect.selinux.html) что приведет к настройки строгой политики SELinux в Debian:
The selinux-policy-default package contains a set of standard rules. By default, this policy only restricts access for a few widely exposed services. The user sessions are not restricted and it is thus unlikely that SELinux would block legitimate user operations. However, this does enhance the security of system services running on the machine. To setup a policy equivalent to the old “strict” rules, you just have to disable the
unconfinedmodule (modules management is detailed further in this section).
На хабре достаточно тем по SELinux: https://habr.com/ru/users/annmuor/publications/articles
Refpolicy (https://github.com/SELinuxProject/refpolicy) является основой, наверное для всех дистрибутивов и он очень хорошо документирован. Во многих случаях SELinux отключать не обязательно, а достаточно перевести его в разрешающий режим и проводить отладку, что является стандартной практикой и в RH, а обширный инструментарий (sepolgen и policygentool и многие другие) помогут лучше разобраться с разработкой политик.
ИМХО модули безопасности SELinux должны писать разработчики ПО т.к. им лучше знать поведение своего детища, и если кто-то из вендоров в инструкции указывает что перед установкой его ПО необходимо отключить SELinux, то кажется что у вендора костыльное представление о безопасности его ПО на данный момент времени, т.к. технология существует уже более 10 лет.
Спасибо за статью. Я как хомячёк считал redhet издателем просто хороших и для сервера дистров и для пк, и внедрятором иноваций безопастности, а теперь знаю чуть больше подробностей почему. Саму идею идею бежать в debian считаю дичью, так как имел неприятный опыт. Тогда уж arch
А если начать с другого... Нужна ли вам защита в вашей ОС на ядре Linux или нет?
Небезопасность Debian