Как AppArmor обрабатывает пространства имен монтирования ядра Linux?

Я искал в вики вики AppArmor, а также пробовал искать в Интернете пространство имен монтирования apparmor (или подобное). Тем не менее, я всегда не понимаю, как с ними справляется AppArmor, что особенно странно, учитывая, что контейнеры OCI не могут существовать без пространств имен монтирования. Принимает ли AppArmor пространства имен монтирования в какую-либо учетную запись или просто проверяет имя файла, переданное какому-то системному вызову?

Если процесс внутри контейнера переключает монтирование пространств имен, AppArmor вообще обращает на это внимание, или он просто монтирует независимо от пространства имен в том смысле, что ему все равно? Например, если процесс-контейнер переключается в исходное пространство имен монтирования, могу ли я написать правила MAC для AppArmor, чтобы предотвратить доступ такого процесса к файлам чувствительного хоста, в то время как те же файлы внутри его собственного контейнера разрешены для доступа?


linux apparmor linux-namespaces
person TheDiveO    schedule 20.02.2021    source источник
comment
Так в чем ваша настоящая проблема?   -  person rkosegi    schedule 20.02.2021
comment
моя проблема заключается в том, чтобы понять или узнать, учитывает ли архитектура AppArmor пространство имен монтирования Linux или нет?   -  person TheDiveO    schedule 20.02.2021

Ответы (2)


arrow_upward
0
arrow_downward

Могу ли я написать правила AppArmor MAC, чтобы предотвратить доступ такого процесса к файлам чувствительного хоста.

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

person rkosegi    schedule 20.02.2021
comment
Тогда ответ на мой вопрос: Нет, AppArmor не учитывает пространства имен монтирования, верно? Мой вопрос касается не монтирования вещей в контейнер, а процесса контейнера, переключающего пространства имен монтирования (конечно, в зависимости от возможностей) и того, может ли AppArmor обрабатывать такие ситуации, по каким бы причинам они ни возникали, например атаки. Если мы можем в любой момент гарантировать, что контейнер не получит доступ к конфиденциальным частям, то зачем мне вообще нужен AppArmor (или другие MAC)? - person TheDiveO; 21.02.2021

arrow_upward
0
arrow_downward

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

Флаг attach_disconnected кратко описан по этой ссылке (несмотря на предупреждение вверху страницы о том, что это черновик): https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference

Следующая ссылка из обсуждения ubuntu apparmor содержит полезную и связанную информацию, хотя и не дает прямого ответа на ваш вопрос. https://lists.ubuntu.com/archives/apparmor/2018-July/011722.html

В следующих ссылках из презентации usenix предлагается добавить пространства имен безопасности в ядро ​​Linux для использования такими фреймворками, как apparmor. Это не показывает напрямую, как / если apparmor в настоящее время использует пространства имен монтирования ядра для принятия решений, но это достаточно связано, чтобы представлять интерес. https://www.usenix.org/sites/default/files/conference/protected-files/security18_slides_sun.pdf https://www.usenix.org/conference/usenixsecurity18/presentation/sun

Я не знаю, является ли мой ответ здесь достаточно полным, чтобы считаться полным ответом на ваши вопросы, однако у меня недостаточно очков репутации, чтобы поместить это в комментарий. Мне также было трудно понять, когда в документации AppArmor имелось в виду пространство имен политики apparmor и пространство имен монтирования ядра Linux, когда пространство имен слова было указано отдельно.

person DericS    schedule 07.06.2021