Comments 26
Первое, что делаешь, когда сервис не может что-то открыть/запустить/увидеть - отрубаешь SELinux. В большинстве случаев - помогает.
Самоё печальное, что даже в операционках, в которых SELinux поставляется включённым по умолчанию, пакеты установленные из штатного системного репозитария - могут нифига не устанавливать нужные им для функционирования права доступа. Даже такой стандарт, как апач.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
Реально, исторические права доступа в Юниксе - это тот разумный минимум, которым будет пользоваться 95%-98% пользователей. Достаточно просто и удобно, чтобы можно было пользоваться постоянно - и достаточно возможностей/функционала, чтобы решить практически все реальные задачи ограничения прав доступа.
Подход, который реализован в SELinux ( и в системе ограничения прав доступа в Windows ) - он продиктован идеей "давайте сделаем супер-пупер систему, пригодную для суперсекретной деятельности". По спецификации уродов из спецслужб США, которым абсолютно насрать на удобство использования, главное - чтобы "секьюрно".
В результате, 99% пользователей даже и не пытаются с этой системой разобраться. А значит, в принципе не пользуются. А если пользуются - то хрен его знает, не открыто ли там чего лишнего.
простите за дурацкий вопрос. Остаюсь перед выбором arch без selinux и secureboot или Fedora с selinux. Насколько важно обычному домашнему пользователю заморачиваться защитой? или все таки стандартной защиты (в arch по моему apparmor) со сложным root паролем хватает? после aur програм (spotify, discord) flatpack кажется очень медленным и хорошенько так грузит систему на ноуте вместе с fedora.
Обычному пк юзеру достаточно проверенных репозиториев и правильно настроенный фаерволл на роутере. Если есть ноутбук, можно заморочиться и с secureboot (на archlinux он есть) и с шифрованием дисков, а остальное, если ты не потенциальная цель для взлома, либо же не открытое для внешнего мира устройство, всем остальным можно пренебречь.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
но если бы он это в ядро внедрил, ее тоже можно было отключать или переводить в Permissive.
А когда она как расширение, получается что мне и в Firewall порты нужно окрывать и еще в Selinux. Могу еще примеров накидать.
Отлично, редко я видел людей, которые пытались решить проблему, а не просто - selinux=0! Браво!
Поработаю капитаном очевидностью, так как сам с ними возился в 2008-2010 гг.
В принципе, если будет время и желание - это всё LSM (linux security module).
Через них проходят все запросы на ядро, и только после одобрения ими дается исполнение или ошибка доступа.
В LSM модулях реализуются куча различных моделей безопасности, и в-принципе, в дистрибутивах есть куча пакетов, под ту или иную типовую модель взаимодействия.
Аудит - это немного другая подсистема безопасности, через неё и идут ошибки или информация.
В принципе, правильно прописанные политики безопасности упрощают жизнь, но для этого нужно составить матрицу доступа - какое приложение куда и с какими правами лезет, куда её пускать нельзя.
Чем спасает от кривонаписанного софта, или его неправильной конфигурации, или ошибок (от них никто не застрахован), когда приложение может делать только то что разрешил администратор.
Но, в большинстве случаев, не разбираясь selinux=0 и пусть голова болит у безопасников.
В данной ситуации проблема не с правами, которые установил пакет с апачем. Пакет 1С живёт в opt и права на модуль в своей папке задавать должен именно он.
При этом предложенное решение "давайте убьём selinux для веб-сервера" умножает большую часть этой защиты на 0. Правильное решение было - для загружаемых модулей установить нужный контекст, чтобы апач мог их загрузить. В этом поможет audit2allow.
А можно поподробней, чем плохо решение которое было в статье setsebool -P httpd_execmem 1
При работе с selinux всегда стоит пользоваться правилом "минимально требуемые разрешения". Ваш вариант - разрешает исполнять вообще любые бинарники в контексте апача.
а как тогда разрешить execmem только для бинарников 1С , я могу только сказать что они в этом каталоге /opt/1cv8/x86_64/8.3.26.1521/ и косвенно что 1С запускает по ходу работы (но это будет не 100% инфа)
Городить кастомную политику? По заголовкам пробежался, понял что уйду в астрал если буду этим заниматься.
Если Вы разрешили порты в Firewall это не значит, что они будут доступны, пока не разрешите их в Selinux
Я вам на винде могу такой же пример дать. Выключен МСЭ, включён SMB. Локально \\hostname\C$ открывается. Удалённо нет. Порт открыт согласно Test-NetConnection hostname -commonport smb. Где искать подземный стук?
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v "LocalAccountTokenFilterPolicy" /t REG_DWORD /d 1 /f
Не могу сказать точно в данном примере, но явно какая то Policy windows запретила smb удаленно. Более простой пример - возможность удаленного коннекта по RDP, там несмотря на открытые порты есть политика которая позволяет это делать.
Но есть разница
Если в Windows политики запрещают или разрешают функционал в целом, то в Selinux
отдельные его части.
Например
semanage port -l | egrep '(^http_port_t|6379)'
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
Явные танцы с портами, которые дублируют функционал firewall .
Тоже с правами на файлы, если они вне каталогов Apache.
Т.е. модульность Linux в данном случае только во вред идет, поскольку функционал дублируется. Если бы включили в ядро как стандарт, можно бы было сделать красиво и согласовано.
Нужно сразу было использовать Astra Linux, вместо Oracle Linux. Конечно же прикупив акции. Тогда и повода для статьи не было. ;-)
Astra linux это дебиан, и кстати они SELinux за основу не стали брать. И дали объяснение
Преимущества использования СЗИ в ОС Astra Linux Special Edition / Хабр
Казалось бы, всё уже есть, и не надо делать ничего своего. Так в чем проблема? А она, как обычно, кроется в фундаменте этих технологий и упирается в математику. Во-первых, несмотря на существующие исходные тексты программного кода AppArmor и SELinux, ввиду его значительного объема и сложности, это не оказывает значительного влияния на возможность проверки эффективности данных механизмов, их доработки, сопровождения, т. е. обеспечения доверия к ним. Во-вторых, собственно доверие к механизмам управления доступом, как правило, основывается на наличии для них формальной (выраженной на математическом языке) модели управления доступом. Без такой модели невозможна верификация как самих AppArmor и SELinux, так и всей системы защиты ОС.
Дело в том, что с одной стороны, формальная модель задает четкие правила игры для ОС, а именно: как назначать права доступа процессам к файлам и каталогам, как их помечать метками конфиденциальности или целостности, управлять доступом на основе этих меток в самых разных ситуациях, например, создания нового файла, учетной записи пользователя или запуска процесса. С другой стороны, модель позволяет на своем уровне абстракции сформулировать условия безопасности ОС и математически доказать, что при их выполнении защиту ОС невозможно взломать.
Однако о существовании развитой модели управления доступом для AppArmor или SELinux авторам настоящей статьи ничего неизвестно. Разработанные в 70-е годы прошлого столетия модели Белла-ЛаПадулы или Биба, иногда упоминаемые в этом контексте, не заслуживают серьезного обсуждения как безнадежно устаревшие. В результате, использовать SELinux или AppArmor для управления доступом в ОС – это сродни созданию отечественного самолета с иностранными двигателями без тщательного тестирования, возможности технической поддержки и развития: летать будет, но долго ли или высоко ли – большой вопрос.
как уже отметили - это база проверять на rhel-based ОС что селинукс что-то запретил, не надо было столько букв писать было.
в целом это вполне даже объяснимая штука - политика selinux для апача и всего остального пишется для работы из коробки, если вы любому бинарнику выдадите дополнительный syscall execmem (кстате достаточно опасному вызову, давно стало стандартом не использовать wx память) результат будет один и тот же, что показывает поиск в гугле по кейворду httpd_execmem, и это еще один повод не писать столькобуков :)
BTW - конструкция "LoadModule 1cwsmodule "/opt/1cv8/x86_64/8.3.26.1521/wsap24.so" это путь вникуда, тк модули достаточно сильно завязаны на версию апача, были случаи когда апгрейд апачу прилетал в рамках ОС (да-да, того самого стабильного rhel-based) и модуль не грузился. но понятно, что это комментарий не вам.
Я хотел показать как разбираться с подобными проблемами, особенно где искать концы.
Кстати а где перечисленны описания всех ресурсов типа execmem? Я чтото гуглом только обрывочные сведения находил
BTW - конструкция "LoadModule 1cwsmodule "/opt/1cv8/x86_64/8.3.26.1521/wsap24.so" это путь вникуда, тк модули достаточно сильно завязаны на версию апача
У 1С более банальная проблема. Вот например я хочу запустить две разные версии 1С (рабочую и для последующего обновления) на одном сервере. Для кластера 1С это не проблема - все разводится по каталогам, сервисам и портам. А вот для Apache это проблема
поскольку LoadModule подразумевает одно имя 1cwsmodule не привязанное к версии 8.3.26.1521
А дальше проблема усугубляется тем, что на одном сервере не получается запустить два apache с одним и тем же LoadModule 1cwsmodule на направленные на разные
"/opt/1cv8/x86_64/!версия!/wsap24.so"
В итоге нужно ставить apache на разные сервера для разных версий 1С и тестить
где перечисленны описания всех ресурсов типа execmem
не понял вопроса - вы хотите из 1с модуля выдрать все syscall, что там использованы?
Вот например я хочу запустить две разные версии 1С
можно с докерами поигратся, в теории должно работать
или, как пишет документация https://httpd.apache.org/docs/2.4/mod/mod_so.html директива LoadModule может быть использована в контексте виртуального хоста. делаете 2 вхоста dev и prod и в каждый грузите свой модуль. вроде просто и проще чем докеры
LoadModule Directive
Description: Links in the object file or library, and adds to the list of active modules
Syntax: LoadModule module filename
Context: server config, virtual hostне понял вопроса - вы хотите из 1с модуля выдрать все syscall, что там использованы?
Банально понять этот запрет означает
type=AVC msg=audit(1741072945.581:125865): avc: denied { execmem }
когда ищешь описание execmem находятся только какие то левые источники.
запрет на выполнение сисколла (в общем случае там могут быть порты, пути и тд) которого нет в политике selinux для данного бинарника
Ну после selinux permisive прописываешь правила, перегрузил правила, для простоты сделал ротацию логов, пользуешься, пока не будет denied.
эти правила добавляешь в штатный набор безопасности - и у тебя и система осталась в защищенном режиме и особо ровная 1С стала работать ровнее. Другое дело - это куча времени.
Разные экземпляры Апача на разных портах каждый со своими настройками будут подгружать разные версии модуля 1с.
Security-Enhanced Linux против 1С + Apache. Выключить нельзя мучаться