Как проверить отказ selinux внутри док-контейнера - PullRequest
0 голосов
/ 14 сентября 2018

У меня есть докер-контейнер, при отключении selinux он работает хорошо; но когда включен selinux (то есть демон docker запущен с --selinux-enabled), он не может запуститься.

Таким образом, сбой должен быть вызван отказом selinux, но это не отображается в журнале аудита selinux. когда я использую «ausearch -m XXX | audit2allow ...» для генерации политики, она не содержит никакой информации об отказе.

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

ps: я проверил информацию метки файла, к которому был получен доступ, они кажутся правильными, но доступ (ls) запрещен:

# ls -dlZ /usr/bin
dr-xr-xr-x. root root system_u:object_r:container_file_t:s0:c380,c857 /usr/bin
# ls /usr/bin
ls: cannot open directory /usr/bin: Permission denied

подробнее: выбранный ответ ответил на вопрос, но теперь проблема заключается в том, что журнал аудита показывает, что доступ состоит в чтении «unlabeled_t», но, как показывает «ls -dZ / usr / bin», это «container_file_t» , Я поставил это в отдельный вопрос: Почему SELinux запрещает доступ к внутренним файлам контейнера и называет их "unlabled_t"?

1 Ответ

0 голосов
/ 18 сентября 2018

Политика, вероятно, содержит dontaudit правила. Dontaudit правила не разрешают acecss, но подавляют ведение журнала для определенного доступа.

Вы можете отключить dontaudit правила с помощью semanage:

semanage dontaudit off

После решения проблемы вы, вероятно, захотите снова включить правила dontaudit , чтобы уменьшить шум журнала.

Также можно найти возможные правила dontaudit с sesearch:

sesearch --dontaudit -t container_file_t
...