Белый список приложений в Linux

А зачем ограничивать доступ к cp и kill? Он все равно не сможет копировать те файлы, на которых не имеет право чтения, и убивать не свои процессы.

И по поводу скриптов: а что мешает выставить эти права только на файлы нужных скриптов? Зачем убирать возможность использовать основные бинарники питона и bash?

Зачем убирать возможность использовать основные бинарники питона и bash?

Чтобы не запустили криптомайнер на питоне или еще что-то подобное, наверное.

Они же на JavaScript в самом браузере пашут, ЕМНИП.

Ну да, просто у питона всё равно больше возможностей. Шифровальщик там можно какой-нибудь подсунуть. Если сделать на питон chmod -x, а на скрипт с #!/usr/bin/pythoon - chmod +x, скрипт будет работать?

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

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

У него OpenSuSe, а они вроде больше на AppArmor ориентированы, он по дефолту идет. Они не будут конфликтовать?

скрипт будет работать?

Нет.

Вот по этому поводу ничего наверняка не скажу. Я только с SELinux работал(на RHEL/CentOS). Да и то, несколько лет назад. Подозреваю, что будут и кого-то одного придётся выпиливать.

По сути Apparmor там как то не включен то есть нет бинарников, а есть библиотеки и по сути выключен не работает. Пока задачи для именно контроля ПО которые запускается нет. А есть задача простая. Это пользователю можно запускать только то что в «whitelist» остальное запретить.

Нет. Стоит SUSE Linux Enterprise Server. Возвращаюсь к своему 2му вопросу. Возможно ли сделать правило именно белого списка «запретить все, что не разрешено?" с помощью именно Apparmor? Не создавая для каждого ПО, утилиты свой профаил и подгружать его в контроль Apparmor?

Слушай, можешь описать подробно задачу? Я сперва понял это так, как будто нужно на десктопе закрыть доступ к пасьянсам или типа того.

По сути так и есть. Это Дескоп, но только с него управляются тех. процессы. (АСУТП). Закрыть нужно все что «не в белом списке» требования безопасности предприятия. Пока об контроле того что делает ПО в процессе работы не идет. (То есть мы ему доверяем Безоговорочно). По сути будет крутиться Scada система. Которая запускает разные скрипты в процессе работы на Bash, pyton. В качестве GUI идет KDE на нем реализован функционал по типу kiosk-а но этого недостаточно и нужен именно «whitelist» приложений.

2. Использовать Apparmor. Но тут сразу вопрос. Возможно ли сделать правило именно белого списка «запретить все, что не разрешено?» кроме того создать для каждого приложения свой профайл как то не реально.

Смотрите в сторону RBAC. http://wiki.apparmor.net/index.php/RBAC_2_3 Профили надо будет сделать только на процессы использующие аутентификацию пользователя через PAM + собственно настроить сам PAM (добавить PAM-модуль Apparmor) + сделать профили шелов для пользователей (в которых и будет «белый список»).

Важно понимать, что список вам надо будет делать не в 5-10 наименования исполняемых файлов (разрешить которые вы хотите), а в 50-100 (т.е. как минимум придется включать в список все компоненты кде, которые после логина пользователя будут запускаться в сессии пользователя, всякие утилиты из coretools и т. д.).

4. LSM-модуля WhiteEgret - про этот вариант прочитал недавно. Как он реализован и как применить его именно в Suse?

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

если у пользователя есть ssh, то он может установить и запустить любое ПО, собрать свой собственный python из исходников и работать с ним

Ты не можешь запретить пользователю что-то запустить, ты можешь ему запретить доступ к каким-то данным и ресурсам, портам, интерфейсам..

если у пользователя есть ssh, то он может установить и запустить любое ПО, собрать свой собственный python из исходников и работать с ним

А если ему chmod +x не дать сделать? Или это нельзя ограничить?

Система не будет иметь выход в сеть интернет. SSH будет по ключам и ограничен netfillter-ом для определенных адресов.

я честно не пойму зачем так извращаться

во-первых, десктоп - это плохой интерфейс для работы в четко ограниченных рамках, он совершенно не предназначен для этой задачи

это выглядит так что в винде мы делали какое-то безобразие с кликаньем мышой по кнопкам и решили сделать также в Linux

В линуксах не принято делать всё через доступ к десктопу, надо использовать протоколы взаимодействия подходящие под задачу: REST, cli, и т.п.

Хочешь ограниченный набор задач - так и сделай его ограниченный изначально.

во-вторых сама постановка задачи безумная. Мы даем права человеку ломать как угодно технологический процесс, но тратим недели на запрет ему запускать пасьянс. Кто у вас в итоге у руля технологического процесса? Человек с тремя классами образования который не понимает в чем его работа? Так его гораздо опаснее допускать к тех.процессу, чем к пасьянсу.

Видимо вы не знакомы с АСУТП и Scada системами. Система управления крутиться в Scada системе из которой и нужно закрыть все выходы в ОС, чтобы чел находящийся у тех.процесса не мог что либо сделать в самой ОС. А что он сделает в тех.процессе все фиксируется логируется в самой Scada. Чел-оператор знает все о тех. процессе, но обычно очень мало знает об ОС. айти и ИБ. Мы бы сделали все на винде, но у разработчика контроллеров , Scada система только под Linux. Разработчик поставляет Scada систему вместе с ОС. Я понимаю, что он должен был изначально задуматься о безопасности ОС. Но тут приходится подстраиваться под конкретного конечного заказчика у которого свои правила по безопасности которые нужно реализовать.

На винде все выглядит понятно. Оснастки не дают выйти в ОС. а встроенный ограниченный список ПО (настраиваемый в 2 клика) блокирует если все же каким то образом чел. смог найти выход в ОС.

Вы не ответили на счет Apparmor можно ли реализовать на нем «Запрещено все, что не разрешено?» и каким образом?

Потому что я работал только с SELinux. :) В теории в AppArmor тоже есть политика белого списка, но я не знаю подробностей её рализации. Беглый поиск показывает, что надо читать.

Не подскажу, как работает apparmor, так как не сталкивался, но не буду орать «ненужно», как некоторые участники. Задача интересная. Я думаю, сначала нужно разобраться, как ограничить список разрешенных exec() для конкретного бинарника. Затем эту политику можно расширить на всего пользователя, чтобы усилить защиту.

В качестве GUI идет KDE на нем реализован функционал по типу kiosk-а но этого недостаточно и нужен именно «whitelist» приложений.

Почему именно не достаточно?

Которая запускает разные скрипты в процессе работы на Bash, pyton.

Потенциальная проблема в этом. Пользователь имеет возможность через интерфейс приложения указать на произвольный файл для запуска в баше или питоне?

В теории можно держать /home/ и /tmp/ на отдельных разделах и монтировать с noexec. В другие разделы системы у пользователя нет прав на запись. C /home/ не проверял, а вот с /tmp/ могут быть проблемы - например, в debian'е при обновлении системы dpkg запускает оттуда pre-install/post-install скрипты. Правда, на время обновления можно просто делать mount -o remount /tmp.

Из вашей ссылки как я понял. Apparmor может ограничивать только по profile's так же поиск в гугле не дал результата. Политика по умолчанию для всех приложений которые вне списка не контролируется Apparmor.

В терминах Apparmor, искомый вами «белый список» для пользователя — это confined user, ограниченный пользователь, подразумевающий полный контроль запускаемых пользователем процессов и доступ к ресурсам. Как правило, в системе нужно сделать 2 типа пользователей — unconfined user (неограниченный, для root и администраторов) и confined user (ограниченный). Делается это через перевод Apparmor в режим RBAC...

Инфа довольная скудная. Реальных примеров не нашел. Как я понял данный режим, реализуется через pam_apparmor.so 1. Не совсем понятно как и где создавать пользователей. 2. Как применить профиль по умолчанию к приложениям для которых отсутствуют профили. 3. pam_apparmor.so прикрутить к /etc/pam.d/xdm для GUI? И нужно ли прикрутить для login? 4. Что передается в этой строке? session optional pam_apparmor.so order=group,default

Если есть время, прошу подсказать куда копать дальше?

Реальных примеров не нашел.

И вряд ли найдете. Возможность переключения режима работы Apparmor в RBAC очень скудно освещена. О ней мало кто знает, а еще меньшее кол-во людей реально использует.

Как я понял данный режим, реализуется через pam_apparmor.so

Да, вы поняли правильно.

1. Не совсем понятно как и где создавать пользователей.

В режиме RBAC, Apparmor работает с существующими пользователями системы. Для работы используется стандартный механизм аутентификации — PAM. Дополнительных действий по созданию пользователей не требуется.

2. Как применить профиль по умолчанию к приложениям для которых отсутствуют профили.

Не совсем понял, что вы подразумеваете под «профиль по умолчанию».

3. pam_apparmor.so прикрутить к /etc/pam.d/xdm для GUI? И нужно ли прикрутить для login?

Я прикручиваю в /etc/pam.d/system-auth, чтобы работало везде. На самом деле, можно ставить туда, куда вы считаете нужным, но следует помнить, что данный процесс должен иметь профиль Apparmor с hat для переключения пользователей.

4. Что передается в этой строке? session optional pam_apparmor.so order=group,default

«order=group,default» — поиск hat по основной группе пользователя, если такой hat не найден, использовать hat по умолчанию. Обратите внимание, что «group» — это поиск только по основной группе пользователя, не по всем группам, в которых состоит пользователь.

Делаешь это неверно. Делается гостевой режим. После каждого выхода из сессии, запускается новая чистая сессия без изменений. Приложение запускается в контейнере или сhroot, директория для сохранения данных мапится на хост, и только в ней сохраняются изменения.

Как я понял у вас уже работает RBAC. Сможете поделиться примером как перевести в RBAC?

Что скажите по поводу TOMOYO и SELinux? Думаю проще на них реализовать.

Как я понял у вас уже работает RBAC. Сможете поделиться примером как перевести в RBAC?

В /etc/pam.d/system-auth добавлена строка

session		optional	pam_apparmor.so order=user,default

Все, режим RBAC включен, теперь остается только делать профили с hat блоками. Например, sudo:

#include <local/tunables.d/>

profile /usr/bin/sudo {

... доступ к ресурсам до аутентификации (переключения на root)

^root {
  
  ... доступ к ресурсам после аутентификации
  
  }
}

Что скажите по поводу TOMOYO и SELinux? Думаю проще на них реализовать.

В TOMOYO нет возможности работать в режиме RBAC, но, можно попробовать реализовать все через условия с uid/gid процесса. На SELinux сделать будет не так просто как на Apparmor, но сделать можно... хотя, делать «белый список» запускаемых программ на SELinux — это явный оверкил (имхо, конечно).

Если вы хорошо знаете TOMOYO или SELinux, то, вероятно, вам будет проще реализовать на них.

Получается в этом режиме так же нужно для каждого приложения составлять файл с правилами? Или как то можно подсунуть по default определенный профайл с запретом?

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

Если немного переработать предыдущий мой пример, реализация белого списка будет выглядеть примерно так:

profile /программа_с_аутентификацией {

... доступ к ресурсам до аутентификации

^имя_пользователя {
  # разрешаем доступ ко всем ресурсам, кроме доступа к файлам:
  ptrace,
  signal,
  unix,
  dbus,
  mount,
  umount,
  network,

  # доступ к файлами (разрешаем все, кроме запуска):
  /** rwklm,

  # собственно, белый список (разрешение на запуск):
  /программа1 Pix,
  /программа2 Pix,
  /программа3 Pix,
  }
}

Pix - запуск с использованием профиля программы (Px), если его нет, запускать с наследованием текущего профиля (ix). Вероятно, у вас установлены базовые профили программ из пакета Apparmor и вы захотите их использовать. Если нет, можно сразу использовать только запуск с наследованием текущего профиля:

  /программа1 ix,
  /программа2 ix,
  /программа3 ix,

Как я уже писал выше, белый список — это совокупность всех программ (включая, например, элементы DE) и утилит (например: mv, cp, ln,...), запускаемых в сеансе пользователя.

Для примера, черный список (разрешаем запускать все, кроме явно запрещенного), будет выглядеть примерно так:

profile /программа_с_аутентификацией {

... доступ к ресурсам до аутентификации

^имя_пользователя {
  # разрешаем доступ ко всем ресурсам:
  ptrace,
  signal,
  unix,
  dbus,
  mount,
  umount,
  network,
  file,

  # собственно, черный список (запрещаем запуск и фиксируем в системном журнале попытки запуска):
  audit deny /программа1 x,
  audit deny /программа2 x,
  audit deny /программа3 x,
  }
}

Оснастки не дают выйти в ОС

Куда? Может всё таки на «рабочий стол»?

Сделай отдельный конфиг для пользователя scada где не запускается DE, а сразу запускается scada система. Если он как-то сумеет её закрыть или уронить, то просто вывалится обратно в sddm (или что там у тебя). А там можно по таймеру перезагружать снова этот же профиль.

И да, тебе не нужен apparmor, тебе нужно запускать пользователя в контейнере (chroot).

Это пользователю можно запускать только то что в «whitelist» остальное запретить.

Древний вариант(не идеальный): chmod og-x на всё не нужное в /usr/bin, /bin и т.д.(и хук на пакетный менеджер, чтоб при обновлении не слетело), все ФС доступные пользователю на запись монтировать с noexec(есть если автомонтирование - с этим придётся повозится).

А вообще плюсую мандатную систему контроля доступа(SELinux или AppArmor - без разницы, что проще будет настраивать - то и настраивай).

если у пользователя есть ssh, то он может установить и запустить любое ПО

с noexec на /home и /tmp и запрещенным запуском компилятора? Как, кроме трюка с ld-linux.so(который ЕМНИП таки можно забанить через SELinux)?

Вам не обязательно запускать десктопное окружение, потому что иксы и десктопное окружение две зависимые, но самостоятельные сущности.

Настройте иксы так, чтобы они при начале сессии запускали не десктоп, а вашу Scada систему как оболочку и всё.

Или вообще не пользуйтесь иксами, а скомпилируйте свою Scada для работы через фреймбуфер.
Может просто напишите свою версию интерфейса.

но у разработчика контроллеров , Scada система только под Linux. Разработчик поставляет Scada систему вместе с ОС.

Эта Scada у разработчика опенсорсный проект?
Если да то свяжитесь с ним и предложите совместную работу над нужными вам улучшениями.
Конечно основную работу придётся делать вам, но зато какую-то часть изменений могут принять в основной проект.

В общем Linux это не винда и разрадотчик может с самого начала предполагать тесное с ним взаимодействие, не бесплатное конечно.

Ещё можно убрать «кнопку „Пуск“» с панели и сменив пользователя для некоторых файлов и каталогов сделать не возможными отмену этих изменений.

Или просто найти где в /usr находится глобальное меню и повыкидывать из него не нужные ярлыки программ.

Ещё можно поменять пользователя для ./Desktop чем не дать создать новые ярлыки для запуска программ, правда с KDE это не поможет, там десктоп функционирует иначе.

Благодарю. Получилось настроить через rbac. Но появился вопрос: Как можно выгрузить загруженный профайл? Манипуляции с выгрузкой модуля

 apparmor_parser -R /etc/apparmor.d/app_profile 

Нашел что можно выгрузить все профайлы через скрипт с опцией teardown.

"/etc/init.d/apparmor teardown"

Есть папка, что-то вроде /etc/apparamor.d/disable - попробуй туда кинуть симлинк на твой профайл.

Создал папку. Перегрузил. Не помогло. pofile все равно подгружается.

Возможно, проблема где-то в yast'e. Попробуй в нем покопаться.

Plugin yast2-apparmor даже не установлен.

выгрузил

 apparmor_parser -R /etc/apparmor.d/app_profile 

загружаю заново

 apparmor_parser -a /etc/apparmor.d/app_profile 

выдает

Skipping profile in /etc/apparmor.d/app_profile

запускаю

apparmor start

профайл подгружается заново

/usr/bin/kdm

Удалил из дир.apparmor.d сам профайл. При загрузке apparmor подгружает его откуда с другого места.

В вашем случае, во время первой загрузки или загрузки измененного профиля при старте сервиса (/etc/init.d/apparmor), создается бинарный кэш. Файлы бинарных кэшей расположены в /etc/apparmor.d/cache/ и имеют такое же имя файла, как и исходный профиль в /etc/apparmor.d/.

По факту, профиль в текстовом виде — «исходный код», а бинарный кэш — «скомпилированный» из «исходного кода» блок данных, загружаемый в модуль ядра. Профили («исходный код») в ядро не загружаются, а используются исключительно утилитой apparmor_parser для создания бинарного кэша и его загрузки в модуль ядра. Для ускорения загрузки, apparmor_parser может сохранять бинарный кэш на диске (что и делает /etc/init.d/apparmor, вызывая apparmor_parser с ключем -W, полагаю).

Сделай отдельный конфиг для пользователя scada где не запускается DE, а сразу запускается scada система. Если он как-то сумеет её закрыть или уронить, то просто вывалится обратно в sddm (или что там у тебя). А там можно по таймеру перезагружать снова этот же профиль.

+1, и выключить все TTY кроме иксового

И да, тебе не нужен apparmor, тебе нужно запускать пользователя в контейнере (chroot).

Ему не нужен чрут, у него система используется строго под одну задачу

О чём идёт разговор?

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

А если разговор о некой средней рабочей станции в вакууме на которой надо запретить некие подозрительные действия опять же внимание вопрос - ctopmbi4 тебе в таком случае чего нужно? Просто запретить или предотвратить и наказать? Но в любом из этих случаев - вочдогс от рута, логируем все процессы и все действия нужного юзера, если процесс не в белом списке делаем нужные действия. Хоть просто убивай процесс по тихому прикидываясь при этом шлангом. Хоть показывай на весь экран «атата». Хоть мыло/смс оправляй. Хоть бригаду добрых мужиков в балаклавах и с демократизаторами на указанный адрес.

каким образом?

Долгим красноглазием.

Благодарю, вроде как работает по крайне мере на виртуалке. Пришлось повозиться, понять, что и как запускается. По поводу пред. траблы с подгрузкой профиля. Решение только путем отката по snapshot, больше такой траблы не возникало. Видимо глюки виртуалки) У меня еще вопрос. Как можно задать default hat для пользователей у которых нет hat в текущем profile?

то есть при таком варианте

order=user,default

Конечно можно создать пустые правила для всех пользователей. Но как то не кашерно). Кстати кто-нибудь в курсе, что случилось с apparmor.net? ресурс не доступен с начала этого года.

Как можно задать default hat для пользователей у которых нет hat в текущем profile?

Есть default hat, который так и называется «^DEFAULT». Все пользователи, у которых явно не задан hat, будут использовать его. Но, есть один нюанс — профиль в режиме complain (обучения), всегда будет искать hat пользователя и не будет переходить на «^DEFAULT». Как только вы загрузите профиль в обычном режиме (enforce), все будет работать как надо и пользователи без профиля будут переходить на «^DEFAULT». Т.е. важно понимать, что «^DEFAULT» выступает в роли fallback и в процессе обучения просто не работает.

Кстати кто-нибудь в курсе, что случилось с apparmor.net? ресурс не доступен с начала этого года.

Все переехало на https://gitlab.com/apparmor, вики можно теперь найти тут: https://gitlab.com/apparmor/apparmor/wikis/home

Рекомендую подписаться на лист рассылки https://lists.ubuntu.com/mailman/listinfo/apparmor. В режиме дайджеста по 1 письму в день приходит и всегда знаешь, что происходит. :-)

Столкнулся с проблемой. В KDE есть приложения которые запускаются через kdeinit4. Соответственно запуск самого kdeinit4 требуется для всех пользователей.

Как ограничить запуск определенных приложений через него не понятно. Так как hat работает только для приложений с авторизацией. И профиль от конкретного пользователя не наследуется его в другой профиль без авторизации. Вы как то решили подобную проблему?