LINUX.ORG.RU

Помогите разобраться с MAC, sandbox и контейнерами

 , , ,


0

2

Если Apparmor используется чтобы ограничивать какие-либо программы в возможностях доступа к каким-либо ресурсам, то в чем его смысл, если условно firejail делает то же самое? Смысл Docker’а - контейнеризация для разработчиков ПО, т.е. его несколько неудобно использовать для обычных пользовательских целей изоляции приложений? Является ли LXC более удобным вариантом, несмотря на то, что он запускает целые операционные системы, пусть и на одном общем ядре? Да и в общем: что лучше использовать в целях изоляции приложений друг от друга и разграничения их разрешений - песочница/контейнеры/MAC (AppArmor в моем случае)?

Извините за повторяющиеся вопросы, но в интернете как-то не получается найти ответы по вопросам, включающим в себя сопоставление данных программ. В этот раз хотя бы сформулировал чуть менее дибильно (вроде).



Последнее исправление: keklol123 (всего исправлений: 4)

Права доступа на файлы тоже используются, чтобы ограничивать программы в возможностях доступа к каким-либо ресурсам, от этого AppArmor и firejail не становятся ненужными. Они про разное, и даже жесткость правил у них совсем разная.

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

Хочешь изолировать софт, не имеешь второго компа и слишком ленив и беспечен для виртуалки? Firejail или bubblewrap. Чего ты хочешь добиться этой темой?

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Хотелось бы изолировать программы с закрытым исходным кодом, чтобы стало немного более приватно, а ненадежные программы действительно можно было бы запускать на виртуальной машине.

keklol123
() автор топика
Ответ на: комментарий от t184256

Песочница — специально выделенная (изолированная) среда для безопасного исполнения компьютерных программ. Обычно представляет собой жёстко контролируемый набор ресурсов для исполнения гостевой программы — например, место на диске или в памяти.

AppArmor — программный инструмент упреждающей защиты, основанный на политиках безопасности (известных также как профили), которые определяют, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение.

Определения согласно википедии. Немного не понятно, чем они отличаются помимо своего исполнения.

keklol123
() автор топика
Ответ на: комментарий от keklol123

Продолжай чтение, желательно на английском. Определение «песочницы» действительно очень размыто, и спектр у него очень широк. По убыванию инвазивности и истончению обертки, я бы назвал такое:

  1. запуск на отдельном железе

  2. полная эмуляция

  3. аппаратно ускоренная виртуализация

(дыра; в моих познаниях?)

  1. эмуляция сисколлов (вайн здесь)

  2. фильтрация сисколлов (seccomp здесь)

  3. мандатная модель доступа (AppArmor здесь)

  4. запуск с обычными ограничениями системы (права доступа к файлам здесь)

  5. запуск без обычных ограничений системы (запуск от рута здесь)

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

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

keklol123
() автор топика
Ответ на: комментарий от t184256

Права доступа на файлы тоже используются, чтобы ограничивать программы в возможностях доступа к каким-либо ресурсам, от этого AppArmor и firejail не становятся ненужными

Становятся уделом тех кто права на файлы настраивать не умеет.

firkax ★★★★★
()
Ответ на: комментарий от t184256

эмуляция сисколлов (вайн здесь)

Нет. Вайн не эмулирует сисколлы, и вайн - совсем не средство управления доступом, у него для этого нет вообще ничего, он только позволяет загружать PE и даёт интерфейс к аналогам виндовых dll (интерфейс к линуксу при этом никуда не девается, просто виндософт обычно не пытается его использовать).

фильтрация сисколлов (seccomp здесь)

Костыль к плохой архитектуре. По-нормальному это должно быть через capabilities.

мандатная модель доступа (AppArmor здесь)

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

Это одно и то же с разных сторон а вовсе не разные уровни.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Вайн не эмулирует сисколлы

Эм, а кто тогда их выполняет? Ядра винды-то нет.

Это одно и то же с разных сторон а вовсе не разные уровни.

Это стена и подпорка от стены.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Никто не выполняет. Виндософт не обращается напрямую к сисколлам (они несовместимые между разными виндами), он использует системные dll, их то и эмулируют. Эмуляцию сисколлов юзерспейсными штуками (которой является wine) сделать было бы невозможно, это надо было бы в линукс-ядро дописывать что-то.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Как виндоdll, дергающие виндовые сисколлы, будут дёргать их напрямую, если ядра винды нет? Че-то либо я сильно не понимаю в принципах работы wine и wsl1, то ли ты что-то невероятное мне рассказываешь.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Потому что там не настоящее ntdll.dll (и ещё несколько) от винды а специальное от wine, которое пользуются нативными средствами хостовой ОС. А остальные dll уже тоже сисколлами не пользуются, а пользуются обёртками к ним из ntdll/kernel32/что там ещё. Если подсунешь ntdll от винды - работать ничего не будет.

Для wsl1 в винде вроде в виндо-ядре эмулятор линукс-сисколлов.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от t184256

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

А вайну их эмулировать незачем - он просто подменяет те системные dll которые их в винде вызывают, на свои, которые работают поверх библиотек линукса.

James_Holden ★★★★
()
Ответ на: комментарий от t184256

Нет конечно. На винде так не делают. У винды нет стабильного стандарта на сисколлы, как у линукса.

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

James_Holden ★★★★
()

AppArmour - это «типа мандатная система контроля (MAC)» («типа», потому что он использует пути к файлам вместо меток безопасности, что в отдельных случаях представляет проблему безопасности).

Политики безопасности MAC определяются заранее, и покрывают все возможные типы доступа субъектов к объектам (во всяком случае, для той части системы, которая выбрана для защиты при помощи MAC). И как только политики вступают в силу, у непривилегированного пользователя нет контроля над доступом в т.ч. и своих объектов.

В отличие от традиционной системы прав UNIX (которая DAC), где например, если я владею файлом, и даже если я не могу изменить владельца файла без обладания моим процессом доп. capability, я все равно могу изменить режим доступа, например, позволить «другим» исполнять мой файл. Т.е. часть решений о контроле доступа в системе делегируется обычным пользователям. В MAC решения контроля доступа не делегируются пользователям, все определяет политика безопасности.

Запуск приложения в песочнице не может заместить MAC, потому что нарушает основной принцип MAC - у пользователя есть свобода выбора в контроле доступа: либо запускать приложение в песочнице, либо нет. Но если, например, политики безопасности MAC намеренно не такие строгие (что логично для десктопа, т.к. степень безопасности обычно обратно пропорциональна удобству использования) или хочется защититься от потенциальной порчи своих собственных данных, можно использовать запуск в песочнице. Но это не замена MAC. MAC на десктопах в основном для того, чтобы если в очередном апдейте дистра какой-то злоумышленник внедрил в ПО уязвимость, ущерб от этой уязвимости будет локализован, даже если это ПО выполнятся с повышенными привилегиями. Весь этот контроль в основном происходит прозрачно для пользователя, и он может и не знать, что вообще какие-то политики безопасности работают в его системе. Совсем другой случай - когда пользователь не доверяет конкретному ПО, от которого хочет защитить свои ресурсы.

seiken ★★★★★
()
Ответ на: комментарий от firkax

мандатная модель доступа (AppArmor здесь)

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

Это одно и то же с разных сторон а вовсе не разные уровни

Это принципиально разные вещи.

hateWin ★☆
()
Ответ на: комментарий от firkax

Принципиальная разница в том, что UNIX права – это ограничение на уровне пользователя. Любая программа, запущенная под твоим пользователем может получить доступ ко всему, к чему имеет доступ твой пользователь. Эта программа может поменять права доступа. MAC – ограничение на уровне приложения. Если твое приложение не имеет доступа к /foo/bar – оно ничего не сможет сделать, даже если получит права root. И без редактирования профиля для этого приложения ты ничего поменять не можешь.

hateWin ★☆
()
Ответ на: комментарий от t184256

Но даже беглого взгляда на AppArmor и SELinux должно хватить, чтобы понять, что они не предназначены условный спотифай огораживать, и на них это делать можно разве что на спор

Почему? У меня огнелис аппармором огорожен.

hateWin ★☆
()
Ответ на: комментарий от hateWin

И что ты огородил, кроме доступа к общей ФС?

Насколько я представляю, Firejail делает приложениям нэймспейсы со своими песочницами, а AppArmor только управляет правами доступа к общей единой помойке.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

И что ты огородил, кроме доступа к общей ФС

По идее, я еще могу ограничить доступ к DBUS. И вместе с доступом к FS ограничена и возможность запуска бинарников. Он не может запускать произвольные бинарники.

hateWin ★☆
()
Ответ на: комментарий от firkax

Ты в самом деле не понимаешь, что такое MAC? Твои права на файлы не защищают от уязвимостей, повышающих привилегии. Права на файлы – это ограничение на уровне пользователя. Все приложения, которые ты запускаешь из-под своего пользователя и имеют доступ ко всему, к чему имеет доступ твой пользователь. Традиционные UNIX permissions никак не позволяют ограничивать отдельные приложения. С помощью того же AppArmor я могу запускать приложение от своего пользователя, и при этом оно гарантированно получит доступ только к тому, что предусмотрено политикой. Без изменения политики нельзя расширить доступ. UNIX permissions – это базовый инструмент. Этого слишком мало.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Пользователь, приложение - это всё гуманитарные ярлыки. Есть субъект доступа, есть список объектов его доступа. По-нормальному это делается как раз UNIX-правами: там готова группировка схожих субъектов с выдачей им общих прав, ну и точная настойка каждого субъекта отдельно тоже разумеется есть, и всё это органично встроено в структуру хранения данных. MAC же это тупые списки, да ещё и прикостыленные сбоку.

Если твое приложение не имеет доступа к /foo/bar – оно ничего не сможет сделать, даже если получит права root

К контексте MAC следует говорить не «права root» а «acl на все файлы и сисколлы». Получит его - так же сможет делать что угодно. Разумеется, в безопасной системе ни права root, ни произвольные acl никому выдаваться просто так не должны.

firkax ★★★★★
()
Ответ на: комментарий от hateWin

Твои права на файлы не защищают от уязвимостей, повышающих привилегии. Права на файлы – это ограничение на уровне пользователя

Опять... MAC это точно такие же привилегии. Их тоже можно повысить через какую-нить уязвимость, отредактировав свои списки доступа. Никакой принципиальной разницы с «уязвимостью на получение рута» тут нет.

своего пользователя

Отойди от этого дурацкого ярлыка. Назначь uid-ы приложениям и вот тебе разделение доступа по приложениям. uid - это идентификатор субъекта доступа, и не надо ограничивать себя в его использовании только «пользователем» в его бытовом понимании. Кстати, почти везде это так или иначе используется для разделения прав разных демонов.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от t184256

AppArmor только управляет правами доступа к общей единой помойке.

Не совсем – AppArmor также позволяет управлять сетевым доступом, правами на монтирование, сигналы, трассировку, POSIX Capabilities, а в ядре Ubuntu – ограничивает доступ к D-Bus.

PeachBlossoms
()
Ответ на: комментарий от goingUp

Так а зачем тебе сисколлы дергать напрямую из приложений, для этого есть обертки в ntdll.dll - вот они более чем стабильны.

И такой подход, как мы видим, позволяет запускать виндовые приложения без ядра винды, без эмуляции его сисколлов, просто подменив dll файлы.

Это же сплошные плюсы.

James_Holden ★★★★
()
Последнее исправление: James_Holden (всего исправлений: 1)
Ответ на: комментарий от t184256

Че-т я понял, что ничегошеньки не понимаю в низкоуровневом программировании под винду.

Просто всё. Есть WinAPI - наборы предоставляемых ОС функций в стандартных поставляемых с ОС dll-библиотеках. К ним и нужно обращаться. Они уже «творят магию». Как эти библиотеки обращаются к Native API, обычно никого не интересует. Calling conventions для обращения к функциям библиотек тоже стандартизированы и описаны в документации для разработчиков. Т.е. абсолютное большинство из того, что может потребоваться, уже заранее обёрнуто в отдельные библиотечные процедуры, и лежит в динамически подключаемых библиотеках, поставляемых с ОС.

QsUPt7S ★★
()
Ответ на: комментарий от firkax

Есть субъект доступа, есть список объектов его доступа

Есть пользователь. И есть объекты – все файлы, доступные твоему пользователю, доступны процессу, запущенному под этим пользователем. Поменять UID – не вариант. Это решение через жопу. Кроме того, если процесс требует рута – никакое жонглирование UID не поможет. А apparmor может огородить тот же smartctl, например.

По-нормальному это делается как раз UNIX-правами

Блджад, да не делается это UNIX правами! Почитай, что такое MAC. Почитай, какую функциональность обеспечивает, например, AppArmor. И подумай.

там готова группировка схожих субъектов с выдачей им общих прав

Скажи, ты русский язык понимаешь вообще? Или ты троллишь? Ведешь себя как типичный витиран юниха: нихрена не понимаешь, но при этом абсолютно уверен в своей правоте. Еще раз, специально для витиранов юниха: UNIX permissions – ограничение на уровне пользователя, пользователь может изменять это ограничение; MAC – ограничение на уровне приложения, расширить доступ/усилить ограничения можно только редактированием политики. UNIX permissions не дают защиты от несанкционированного повышения привилегий. Они не обеспечивают нужно гибкости. Они не могут ограничить приложение, работающее под рутом. Так доступно?

hateWin ★☆
()
Ответ на: комментарий от hateWin

Это решение через жопу.

Избавься от своих шаблонов и всё станет понятнее. Файлы доступны не пользователю, а низкоуровневому uid-у. То, что ты на этот uid цепляешь понятие пользователя - твоё личное дело. Делать это совершенно не обязательно.

Кроме того, если процесс требует рута – никакое жонглирование UID не поможет.

Перефразирую: если процесс требует лишних прав, то их ограничение не сработает. Рут это или неадекватные попытки лезть куда не надо - не суть. Решения два: либо разрешить проге всё что она хочет (запустить от рута/выключить mac), либо пофиксить прогу чтобы не лазила куда не следует.

Блджад, да не делается это UNIX правами! Почитай, что такое MAC. Почитай, какую функциональность обеспечивает, например, AppArmor. И подумай.

Ну там не только доступ к файлам, да. Есть и другие ограничения, но я просто на примере файлов показываю всю костыльность mac. Часть других функций реализована (более адекватно, хотя и там не идеал) в capabilities, часть, может вообще нигде. А вот не было бы этих apparmor-ных костылей, может сделали бы нормальное управление детальными правами.

UNIX permissions – ограничение на уровне пользователя, пользователь может изменять это ограничение

Ты бредишь. Вот у тебя есть пользователь (не рут), suid бинарников (которые можно взломать) рядом нет, и есть файл /dev/sda, которому unix-правами (uid=gid=0, mode=0600) тебе закрыт доступ. Измени это ограничение и хотя бы прочитай содержимое.

Они не могут ограничить приложение, работающее под рутом. Так доступно?

Это тавтология. Приложение под рутом означает что в концепции unix-прав ему выданы полные права на всё и его соответственно ограничивать и не нужно. MAC тоже не может ограничить приложение, если по условию задачи у него полный доступ ко всему без ограничений.

С аппармором тебе нужно найти две уязвимости. Без аппармора – одну. Ферштейн?

Ну разве что так. Компенсируем общее низкое качество безопасности (везде баги и дыры) накидыванием дополнительных её слоёв, авось хоть один не смогут взломать.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Перефразирую: если процесс требует лишних прав, то их ограничение не сработает

Запусти smartctl без «лишних прав». Или попробуй написать apparmor профиль и посмотри, как оно «не работает».

hateWin ★☆
()
Ответ на: комментарий от firkax

Ты бредишь. Вот у тебя есть пользователь (не рут), suid бинарников (которые можно взломать) рядом нет, и есть файл /dev/sda, которому unix-правами (uid=gid=0, mode=0600) тебе закрыт доступ. Измени это ограничение и хотя бы прочитай содержимое

Во-первых, если какой-либо процесс, запущенный с правами твоего пользователя, сможет повысить свои полномочия до рута, он сделает с правами на /dev/sda все, что угодно. Во-вторых, до /dev/sda он, может, и не доберется, а выставить 777 на твой домашний каталог и все, что там лежит – вполне. Кроме того, ты опять не в ту сторону воюешь. Я хочу ограничить отдельное приложение так, что бы оно не могло получить доступ ко всем файлам, которые доступны моему пользователю, а только тем, которые нужны для его работы. И чтобы приложение гарантированно не могло ничего сделать с этими файлами, даже если процесс по каким-либо причинам получит рута. Решай эту задачу без MAC. Удачи тебе.

hateWin ★☆
()
Ответ на: комментарий от firkax

Это тавтология. Приложение под рутом означает что в концепции unix-прав ему выданы полные права на всё и его соответственно ограничивать и не нужно

Это феерическая чушь. Пользователи systemd-nspawn, doker, smartctl, libvirt смотрят на тебя как сам знаешь на что.

hateWin ★☆
()
Последнее исправление: hateWin (всего исправлений: 1)
Ответ на: комментарий от firkax

Ну разве что так. Компенсируем общее низкое качество безопасности (везде баги и дыры) накидыванием дополнительных её слоёв, авось хоть один не смогут взломать

Опять сказки из параллельной реальности. Витираны такие витираны.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Ты в который раз упорно пишешь про какие-то повышения прав. Я в который раз тебе отвечу: то, что в контексте unix-прав называется повышением до рута, в контексте mac называется редактированием своего acl до максимальных разрешений.

Вот к этому

даже если процесс по каким-либо причинам получит рута

надо не забывать это

даже если он найдёт способ прописать себе все нужные права

т.к. это равноценные события.

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

Например: ставишь на нужные файлы (и пути к ним) группу, которую выдаёшь этому приложению, и соответственно g+r g+w g+x в нужных местах. Само приложение, разумеется, запускаешь не с основным uid своей сессии, а с каким-то другим.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Избавься от своих шаблонов и всё станет понятнее. Файлы доступны не пользователю, а низкоуровневому uid-у. То, что ты на этот uid цепляешь понятие пользователя - твоё личное дело

Какая накуй разница? Если процесс запущен с UID моего пользователя – ему доступны все ресурсы, доступные моему пользователю. Окей. Я меняю UID процесса. Получаю кучу проблем. С dbus, с аудио, с графикой, с доступом к ресурсам, принадлежащим моему пользователю, с громоздкостью и тупизной этого решения. У приложения по-прежнему есть выход в сеть, даже если это ему не нужно. У приложения есть доступ ко всем capabilities, даже если они ему не нужны и так далее. Короче, твое решение не соответствует принципу наименьших привилегий.

hateWin ★☆
()
Ответ на: комментарий от firkax

в контексте mac называется редактированием своего acl до максимальных разрешений

Во-первых, MAC и ACL – разные вещи. Во-вторых, каким хером процесс сможет отредактировать что-либо в /etc/apparmor.d/, если я не дал ему такого разрешения в профиле? Я настоятельно рекомендую тебе почитать, что означает Mandatory Acces Control. Еще раз, пользователь не может самостоятельно изменить ограничения (если специально не дать ему этой возможности).

hateWin ★☆
()
Ответ на: комментарий от hateWin

феерическая

Феерическое ненужно эти твои systemd и docker.

Что касается smartctl, то что ты от него хочешь? Дать ему право слать диску смарт-команды, но не дать право читать/записывать сектора? Ну да, стандартными нормальными средствами так не получится. AppArmor от этого меньшим костылём не становится.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты в который раз упорно пишешь про какие-то повышения прав

Я тебе уже привел пример с хомяком. Удаление, отправка в интернеты, изменение прав на 777 и так далее. UNIX права от этого НИКАК не защищают. Как тебе это объяснить?

hateWin ★☆
()
Ответ на: комментарий от firkax

Феерическое ненужно эти твои systemd и docker

Этот витиран порвался, несите нового.

Дать ему право слать диску смарт-команды, но не дать право читать/записывать сектора? Ну да, стандартными нормальными средствами так не получится. AppArmor от этого меньшим костылём не становится

/0. Хорошо, что ты признаешь, что UNIX permissions дают только самый базовый уровень защиты и их совершенно недостаточно. Но как ты умудряешься сразу после этого писать, что apparmor костыль – мне непонятно.

hateWin ★☆
()
Ответ на: комментарий от firkax

Феерическое ненужно эти твои systemd и docker

Забавно, что ты libvirt проигнорировал :) Это тоже ненужно? У луддитов куда ни ткни – все ненужно. А потом они еще возмущаются, почему их любимые технологии закапывают.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Получаю кучу проблем. С dbus, с аудио, с графикой, с доступом к ресурсам, принадлежащим моему пользователю, с громоздкостью и тупизной этого решения.

Ну что тут сказать - костыль на костыле, стоит чего-то вытащить как всё сыпется. По хорошему, доступы и в dbus, и ко всему остальному перечисленному должны были настраиваться теми же unix-правами, тогда бы всё органично вписалось. Но да, видимо не везде так поэтому имеем что имеем.

У приложения по-прежнему есть выход в сеть

В линуксовом файрволле вроде есть правила по uid.

У приложения есть доступ ко всем capabilities

Каким всем? По дефолту их вроде наоборот нет, если ты не рут.

Во-первых, MAC и ACL – разные вещи.

Как ещё назвать MAC списки доступа если не ACL?

Во-вторых, каким хером процесс сможет отредактировать что-либо в /etc/apparmor.d/, если я не дал ему такого разрешения в профиле?

Никаким. Так же как процесс сам себе не может setuid(0) сделать если он заранее не рутовый. О чём я и пишу в который раз.

firkax ★★★★★
()
Ответ на: комментарий от hateWin

Удаление, отправка в интернеты, изменение прав на 777 и так далее. UNIX права от этого НИКАК не защищают.

Защищают, если uid процесса - не owner хомяка.

Хорошо, что ты признаешь, что UNIX permissions дают только самый базовый уровень защиты и их совершенно недостаточно.

Я такого не писал.

Забавно, что ты libvirt проигнорировал

libvirt это обёртка над виртуалками, насколько я знаю, то есть к правам внутри системы отношения практически не имеет.

firkax ★★★★★
()