SELinux - канонический способ автоматического применения контекста на создании файла
Лучший способ состоит в том, чтобы сказать rabbitmq не искать имя хоста. Можно сделать то использование rabbitmq файл конфигурации.
отредактируйте конфигурацию, создайте ее, если она не существует
vim /etc/rabbitmq/rabbitmq.conf
vim /etc/rabbitmq/rabbitmq-env.conf (in later versions of RabbitMQ)
Добавьте следующие записи:
NODENAME=rabbit@localhost
NODE_IP_ADDRESS=127.0.0.1
Ядро выполняет следующую процедуру, чтобы определить, каким будет тип файла для вновь созданного файла.
- В политике существует определенное правило перехода файлов. Так что примените это.
- Заставьте вновь созданный файл получить тип родительского каталога.
В подавляющем большинстве случаев новые файлы наследуют тип родительского каталога. Иногда это нежелательно - поэтому разработчик политики может создавать правила, основанные на условиях того, кто и где выполняет маркировку, для перехода к другому типу.
Это контролируется политикой с помощью type_transition ], хотя обычно писатель политики вместо этого вызывает макрос filetrans_pattern .
В ядре эти решения основаны не на путях, а на типах (хотя в более новых политиках существует небольшое исключение).
Правило обычно выглядит так:
type_transition httpd_t var_log_t: file httpd_var_log_t;
В этом примере правило гласит это. Если процесс / пользователь, выполняющий создание файла, - httpd_t , а каталог, в котором создается объект, - var_log_t , и объект классифицируется как файл , то новый файл должен быть помечен как httpd_var_log_t .
Это, конечно, имеет ряд ограничений, хорошим примером этого является условие, когда вы создаете файлы .htaccess в apache (в / var / www / html). В этом примере применяется политика по умолчанию для создания типа файла с тем же типом, что и его родительский каталог, но в действительности правильный тип этого файла - httpd_sys_htacess_t , а не httpd_sys_content_t по умолчанию.
Это была известная проблема в течение ряда лет, и в конечном итоге она была исправлена, позволив разработчикам политик указать имя файла, к которому применяется переход в политике - к сожалению, эта функция недоступна в EL6.
В вашем конкретном случае - как вы упомянули, есть несколько обходных путей, связанных с restorecond. Помимо этого, вы должны в идеале разделить свои данные на разные типы, поместив их в отдельные подкаталоги, где подкаталог является соответствующим типом. Если это по-прежнему невозможно, и restorecond невозможен - единственное решение - это пост-исправление запуска restorecon для файла после его создания.
Даже «более новый» с именем filetrans имеет проблемы, потому что в конечном итоге он не поддерживает globbing или regex, что сильно ограничивает его функциональность до файлов с определенными именами (например, .htaccess).
Это не проблема, вы просто приближаетесь к ней с неверного направления.
Если вам нужны собственные файловые контексты , просто создайте свой, используя semanage fcontext . Этот действительно принимает регулярные выражения.
Вот общий пример, используемый для перемещения каталога, из которого Apache обслуживает файлы :
semanage fcontext -a -t httpd_sys_content_t "/volume1/web(/.*)?"
Не стесняйтесь адаптировать это к своим потребностям .
Проблема правильной маркировки при создании файла была решена в Fedora 16 с помощью функции под названием переход имени файла (хотя вы можете найти его также как «именованные переходы файлов»), определение которого в основном гласит:
С помощью функций перехода имен файлов разработчики политик могут писать правила, учитывающие имя файла. , а не путь к файлу. Это базовое имя пути к файлу. Так как ядро во время создания объекта знает метку содержащего каталога, метку процесса, создающего объект, и имя объекта. Теперь мы можем написать правило политики, которое гласит, что если процесс unlimited_t создает файл с именем resolv.conf в каталоге с меткой etc_t, файл должен иметь имя resolv.conf.
Известно, что способ пометки объекта во время создания может варьироваться в зависимости от процесса, создающего объект ( cp vs. mv - хороший пример). Кроме того, по умолчанию объекту присваивается метка по наследству: объект получает метку родительского каталога.
Хотя это удобно, но не всегда правильно, и системный администратор должен исправить ситуацию вручную, используя (a комбинация) restorecon + restorecond + semanage fcontext -a -t .
Это проблема, которую пытаются исправить переходы файлов имен, разрешив
[...] разработчики политик имеют возможность перезаписать это, написав правило в политике, которое гласит, что если процесс с типом a_t создает объект класса «файл» в каталоге с меткой b_t, объект будет создан c_t.
Очевидно, именованные переходы файлов не существуют для пользовательских расположений. Вы можете найти уже существующие, например:
# sesearch -ASCT -s unconfined_t | grep Found
...
Found XX named file transition filename_trans:
...
Итак, чтобы решить вашу проблему, вам нужно заранее знать, какой пользователь (пользователь SELinux) создаст, какой файл / каталог и где, а затем написать собственную политику, включая файловый переход. На вики-странице проекта Fedora, на которую я ссылался выше, есть несколько примеров.