Я пытаюсь настроить пользовательский SELinux
policy, но у меня возникают проблемы с переходом домена, когда двоичный файл приложения находится за пределами стандартных двоичных каталогов, таких как /bin
, /usr/bin
и т. д. Необходимо, чтобы двоичный файл приложения находился вне этих каталогов.
В целях тестирования у меня есть программа, которая просто печатает текущий SELinux
домен. У меня есть домен my_domain_t
, а тип my_domain_exec_t
. Переход к my_domain_t
настраивается, чтобы происходить, когда процесс в unconfined_t
домен выполняет файл с my_domain_exec_t
контекст.
Если я скопирую тестовый двоичный файл в /data
каталог, установите его контекст и выполните его, домен не изменится.
$ cp getcontext /data/getcontext
$ chcon -t my_domain_exec_t /data/getcontext
$ /data/getcontext
unconfined_t:unconfined_r:unconfined_t:s0-s0:c0.c1023
Если вместо этого я скопирую тестовый двоичный файл в /usr/bin
каталог, установите его контекст, а затем выполните его, переход домена происходит правильно.
$ sudo cp getcontext /usr/bin/getcontext
$ sudo chcon -t my_domain_exec_t /usr/bin/getcontext
$ /usr/bin/getcontext
unconfined_t:unconfined_r:my_domain_t:s0-s0:c0.c1023
Я считаю, что в ходе тестирования я устранил все, что связано с пользователем, запускающим файлы, владельцем файлов или контекстом безопасности родительского каталога. Что еще могло вызвать эту разницу?
Редактировать: /data
не монтируется по NFS. Контекст /data
является system_u:object_r:default_t:s0
. В другой системе, которую я тестировал, я также видел /data
маркированный system_u:object_r:etc_runtime_t:s0
.
policy_module(my_domain, 1.0.0)
require {
type unconfined_t;
}
type my_domain_t;
type my_domain_exec_t;
role unconfined_r types my_domain_t;
allow unconfined_t my_domain_exec_t:file *;
allow my_domain_t my_domain_exec_t:file { rx_file_perms() };
allow unconfined_t my_domain_t:process { transition siginh setexec };
type_transition unconfined_t my_domain_exec_t: process my_domain_t;
Это самая простая из почти 20 версий созданной мной политики, и она отображает описанное поведение. Я также пробовал domain_trans
, domain_auto_trans
, и domain_entry_file
макросов, а также создание политики с sepolgen
инструмент, который использовал domtrans_pattern
макрос.
SElinux не особо заботится о путях к файлам.
Я не могу воспроизвести вашу проблему. Я использую staff_r
роль и staff_t
введите в Fedora 20, но это, похоже, эффективно воспроизводит вашу проблему.
Моя программа:
#include <stdio.h>
#include <stdlib.h>
#include <selinux/selinux.h>
int main() {
security_context_t con;
if (getcon(&con) < 0) {
perror("Cannot getcon");
return 1;
}
printf("%s\n", con);
freecon(con);
return 0;
}
Моя политика.
policy_module(getcon, 1.0.0)
require {
role staff_r;
type staff_t;
}
## Type defs
type getcon_exec_t;
type getcon_t;
application_domain(getcon_t, getcon_exec_t)
## Role permits
role staff_r types getcon_t;
## Transitions
domain_auto_transition_pattern(staff_t, getcon_exec_t, getcon_t);
## Access vectors
allow getcon_t staff_t:process sigchld;
userdom_use_inherited_user_ptys(getcon_t);
Чтобы скомпилировать программу:
gcc -o getcon getcon.c -lselinux
Чтобы скомпилировать и загрузить политику:
make -f /usr/share/selinux/devel/Makefile load
Запуск без изменения контекста
$ ./getcon
staff_u:staff_r:staff_t:s0-s0:c0.c1023
Изменение контекста:
# chcon -t getcon_exec_t getcon
$ ./getcon
staff_u:staff_r:getcon_t:s0-s0:c0.c1023
Изменение родительского каталога на default_t:
# chcon -t . default_t; chcon -t getcon_exec_t getcon
$ ./getcon
staff_u:staff_r:getcon_t:s0-s0:c0.c1023
Вы можете попробовать использовать мою политику в качестве основы, если хотите. Но это, похоже, на меня не влияет.