Как следует создавать и маркировать исходные файлы в настраиваемой политике SElinux?

Резюме

Учитывая настраиваемую политику, разрешающую тип файла blue.files к /blue как следует первоначально Создайте /blue с заводской табличкой blue.files?

Задний план

Примечание: этот вопрос возник в результате попытки затянуть Удика сформированная политика. Удика использует CIL синтаксис. CIL не часто встречается в примерах SELinux. Не стесняйтесь мысленно заменять blue_files_t для blue.files и blue_process_t для blue.process.

Существующие примеры

В сети есть примеры переименования каталогов с существующими типами контента. Например:

$ semanage fcontext -a -t httpd_sys_content_t /web
$ restorecon /web

Однако это невозможно с совершенно новым типом файлов. Политика httpd позволяет переименовывать файлы других типов как httpd_sys_content_t а также разрешить типы процессов, отличные от httpd_t сделать это перемаркировку. См. Вывод sudo sesearch --allow -t httpd_sys_content_t -p relabelto

Чего не хватает

При создании политики для новой услуги blue.process например, было бы проще ссылаться на как можно меньше внешних доменов. С другой стороны, что-то кажется неправильным в том, чтобы разрешить другим доменам доступ на запись к /blue если blue.process предполагается, что это отдельная служба.

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

Домен:
- blue.process
- не-blue.process (вероятно, администраторский тип)
Разрешения:
- перемаркировать /blue из не-blue.files к blue.files
- Создайте /blue с blue.files ярлык изначально (как?)
- другие разрешения, о которых писатель не знает

Альтернативы

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

Или есть sudo-подобная команда для администратора, чтобы запускать вещи как blue.process тем самым позволяя политике действовать самостоятельно без ссылок на внешние домены?

Выходя за рамки вопроса: Удика предоставляет лоты политики. (semodule --cil --extract container выдает тысячи строк!) Есть ли что-то в этой политике, что следует использовать неявно?

Выход за рамки принудительного применения SELinux: есть ли способ маркировки /blue с участием blue.files до того, как SELinux начнет принудительное исполнение?

Минимальный пример

$ # System
$ cat /etc/centos-release
CentOS Linux release 8.1.1911 (Core)
$ getenforce
Enforcing
$ sudo dnf install udica
Package udica-0.2.1-2.module_el8.1.0+298+41f9343a.noarch is already installed.
...snip...

$ # Example policy, initially generated via Udica, 
$ # then modified to associate blue.files with /blue 
$ cat blue.cil
(block blue
    (blockinherit container)
    (allow process process ( capability ( chown dac_override fsetid fowner mknod net_raw setgid setuid setfcap setpcap net_bind_service sys_chroot kill audit_write )))
    (type files)

    (allow process files ( dir ( open read getattr lock search ioctl add_name remove_name write )))
    (allow process files ( file ( getattr read write append ioctl lock map open create  )))
    (allow process files ( sock_file ( getattr read write append open  )))
)
(roletype object_r blue.files)
(filecon "/blue"  dir (unconfined_u object_r blue.files  ((s0) (s0))))
(filecon "/blue/.*"  file (unconfined_u object_r blue.files  ((s0) (s0))))

$ sudo semodule -i blue.cil /usr/share/udica/templates/base_container.cil

$ sudo semanage fcontext -l |grep blue.files
/blue                                              directory          unconfined_u:object_r:blue.files:s0
/blue/.*                                           regular file       unconfined_u:object_r:blue.files:s0

$ # check the permissions on those contexts
$ sesearch --allow |grep blue.files
allow blue.process blue.files:dir { add_name getattr ioctl lock open read remove_name search write };
allow blue.process blue.files:file { append create getattr ioctl lock map open read write };
allow blue.process blue.files:sock_file { append getattr open read write };

$ sudo mkdir /blue
$ ls -dZ /blue
unconfined_u:object_r:default_t:s0 /blue

$ sudo chcon unconfined_u:object_r:blue.files:s0 /blue
chcon: failed to change context of '/blue' to ‘unconfined_u:object_r:blue.files:s0’: Permission denied

$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent | audit2allow
#============= unconfined_t ==============
allow unconfined_t blue.files:dir relabelto;

$ # Hmmm, the idea is to keep /blue only available to blue.process.
$ # Is allowing unconfined_t relabeling permissions the right thing?
$ ps -Z
LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1228 pts/2 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 5627 pts/2 00:00:00 ps

$ # Well, unconfined_t seems to be "me"... let's ask the gurus on the web

Спасибо!