LINUX.ORG.RU

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

 , , ,


0

2

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

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



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

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

Ага. И «работает» это только для однострочников на баше. Что-то более сложное реализовать такими костылями – это садо-мазо. И все равно функциональности MAC это не обеспечивает.

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

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

Если uid не owner хомяка – опять садо-мазо с графикой, звуком, dbus, доступам к файлам, с которыми ты хочешь работать и owner-ом которых является твой основной пользователь. И, как я сказал уже 100500 раз, это все равно не замена MAC. Еще раз, это неудобно. Это менее безопасно, чем MAC. Это абсолютно неюзабельно, если огораживаемое приложение сложнее однострочника на баше.

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

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

Да прочитай ты, что такое MAC, и чем он отличается от DAC.

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

Прочитал. Описывают так: в DAC владелец управляет доступом к ресурсу, в MAC не управляет. По-моему это можно очень упростить: если ты не владелец ресурса то у тебя получается MAC, если владелец то DAC. Но поскольку правила для MAC всё же кто-то сочиняет - то вот он и есть владелец и для него это уже DAC. Предвижу, ты опять начнёшь придираться к формулировкам, приплётешь рута итд. Отвечу сразу: отделяй низкоуровневые алгоритмы (unix-права, тот же apparmor итд) от высокоуровневых сущностей, с помощью них реализуемых. MAC/DAC - то именно высокоуровневые сущности, определяемые людьми, а unix-права и apparmor - алгоритмические инструменты для реализации. Повторяю своё мнение: то, что называют MAC, можно реализовать и unix-правами, и никаких кардинальных отличий от т.н. DAC нет. Разница только в том, кто владелец (= кто управляет правами).

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

Что-то более сложное реализовать такими костылями – это садо-мазо.

Мне кажется тут проблема не в инструменте, а в архитектуре, которая изначально строилась без оглядки на безопасность. И тут да, костылём всё «исправить» проще и быстрее, но всё равно это костыль.

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

Ну это очень специфичный случай. А так, если в самом деле нужно настолько детально расписать права, то лучше то было бы делать чем-нить типа capabilities, которые могут принадлежать процессу, либо быть в стиле setuid приписанными к бинарнику. Но не в виде списков разрешений в каких-то посторонних файлах в /etc. Я не понимаю, как тебе в глаза не бросается чужеродность этого подхода вообще.

Впрочем, я одну дурацкую утилиту с похожим подходом знаю - это sudo. Там аналогичная беда: вместо того чтобы прописывать права на запуск в метаданных файла (chgrp, chmod g+x, setuid) или в самом бинарнике (который смотрит разрешения по алгоритму), они прописываются списком где-то в etc у посторонней программы, да ещё и в виде регулярок на целую командную строку, выкидывая понятие списка аргументов.

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

Повторяю своё мнение: то, что называют MAC, можно реализовать и unix-правами, и никаких кардинальных отличий от т.н. DAC нет.

Не совсем – unix-права в основном доступом к файлами управляют. Например, не удастся ограничить доступ к сетевым сокетам и абстрактным unix-сокетам (если не путаю) чере unix-права (по крайней мере, только ими, если не учитывать файрвол и проверку uid на другой стороне unix-сокета). Не ограничивает POSIX capabilities и права на монтирование, более того, не удастся достаточно гибко настроить ограничения.

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

Ну это очень специфичный случай

Епт. Я тебе перечислил несколько приложений, которым нужен рут и которые хотелось бы ограничить в возможности нашкодить. Еще раз – ты про принцип наименьших привилегий вообще слышал?

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

Впрочем, я одну дурацкую утилиту с похожим подходом знаю - это sudo. Там аналогичная беда: вместо того чтобы прописывать права на запуск в метаданных файла (chgrp, chmod g+x, setuid)

setuid – дыра в безопасности. Во-вторых, твой подход в принципе небезопасен. Он не позволяет давать права только тогда, когда нужно.

dd if=/dev/zero of=empty

Не требует никаких особых привилегий.

А dd if=/dev/urandom of=/dev/sda – требует. С твоим подходом он всегда будет запускаться с повышенными привилегиями. Даже когда это на йух ненужно.

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

А так, если в самом деле нужно настолько детально расписать права, то лучше то было бы делать чем-нить типа capabilities

capabilities – это вообще не то.

А так, если в самом деле нужно настолько детально расписать права, то лучше то было бы делать чем-нить типа capabilities, которые могут принадлежать процессу, либо быть в стиле setuid приписанными к бинарнику. Но не в виде списков разрешений в каких-то посторонних файлах в /etc. Я не понимаю, как тебе в глаза не бросается чужеродность этого подхода вообще.

Опять какая-то шизофазия. «чужеродность этого подхода вообще» – это уже религия. С религией – к батюшке, мулле, гуру и так далее. Не вижу ничего страшного в профилях, которые лежат в /etc.

Как ты вообще собрался сколь-нибудь сложное правило в атрибутах файла прописывать? Как это потом редактировать? В AppAromr все просто: отредактировал профиль, выполнил apparmor_parser -r $PROFILEFILE – все готово. Кроме того, один и тот же бинарник может запускаться пользователем, а может запускаться другим бинарником. Он может запускаться разными бинарниками, и, в зависимости от контекста, ограничения могут быть совершенно разными. С профилями это очень удобно реализуется.

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

Они разные только у тебя (и ещё у кого-то) в голове. По факту они дублируют функционал друг друга (по крайней мере если речь про файлы), только в unix permissions оно сделано удобно и логично, а в apparmor - костыльно (в т.ч. как костыль для нейтрализации других костыльных сущностей типа dbus). Да, apparmor покрывает несколько больше случаев, но это уже особенности реализации. Главное идеологическое отличие между ними в том, где хранить настройки. По нормальному настройки хранятся привязанными к объектам/субъектам прав, по-костыльному - списками всяческих текстовых строк где-то в левом хранилище настроек.

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

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

Они разные только у тебя (и ещё у кого-то) в голове. По факту они дублируют функционал друг друга

Я даже не знаю, что бы тебе ответить и при этом избежать снятия скора по 5.{1,2}. Ты точно русский язык понимаешь? Может тебе на клингонском написать надо?

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

Если ты пишешь глупости то они на любом языке остаются глупостями. И от того что ты 10 раз их повторишь - они тоже глупостями быть не перестают. Ты уже раз 10 повторяешь свою мантру «MAC это другое», но ни одного осмысленного аргумента не привёл. Все твои аргументы:

1) в MAC «владелец» ресурса не управляет доступом к нему - я на это уже ответил (тут чисто манипуляция названиями, называть владельцем не владельца)

2) MAC лучше стыкуется с костыльными сущностями типа dbus и прочими, которыми полон десктопный линукс - тут дело не в mac как таковом, а в его конкретной реализации, где костылями подпёрты другие костыли

3) у MAC больше покрытие (всякие там фильтры по смарт-командам) - это опять не в MAC дело а в его конкретной реализации

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