Если matchpathcon проверяет контекст SELinux каталога, какова обратная проверка для службы?

Я буду использовать passwd программа, чтобы объяснить многое из этого.

Чтобы однозначно ответить на этот вопрос в контексте DAC (стандартная модель управления доступом unix):

Как понять из файла, в какой теме я могу запустить двоичный файл?

Ответ - ты бежишь ls -l /bin/passwdпроверьте, установлен ли бит setuid. Если это так, вы запустите программу как владелец файлов, в противном случае вы запустите программу как собственный пользователь.

Чтобы однозначно ответить на этот вопрос в контексте SELinux:

Как понять из файла, в какой теме я могу запустить двоичный файл?

Что ж, не все так просто, потому что это зависит от ВОЗ вы когда пытаетесь запустить двоичный файл! К счастью, sesearch Утилита невероятно удобна для проверки того, какой может быть политика в этом случае. Мы можем попросить его сообщить нам, какие все переходы могут произойти при запуске объекта с меткой httpd_exec_t.

Что дает

$ sesearch -T -c process -t httpd_exec_t
Found 14 semantic te rules:
    type_transition system_cronjob_t httpd_exec_t : process httpd_t; 
    type_transition crond_t httpd_exec_t : process httpd_t; 
    type_transition certwatch_t httpd_exec_t : process httpd_t; 
    type_transition initrc_t httpd_exec_t : process httpd_t; 
    type_transition dirsrvadmin_t httpd_exec_t : process httpd_t; 
    type_transition kdumpctl_t httpd_exec_t : process httpd_t; 
    type_transition cluster_t httpd_exec_t : process httpd_t; 
    type_transition logrotate_t httpd_exec_t : process httpd_t; 
    type_transition condor_startd_t httpd_exec_t : process httpd_t; 
    type_transition cobblerd_t httpd_exec_t : process httpd_t; 
    type_transition openshift_initrc_t httpd_exec_t : process httpd_t; 
    type_transition piranha_pulse_t httpd_exec_t : process httpd_t; 
    type_transition init_t httpd_exec_t : process httpd_t; 
    type_transition svc_run_t httpd_exec_t : process httpd_t;

Оказывается, в вашем случае на самом деле есть множество разных субъектов, которые могут это делать, все они попадают в домен httpd_t.

Но это всегда так: -

$ sesearch -T -c process -t ssh_exec_t
Found 8 semantic te rules:
   type_transition virsh_t ssh_exec_t : process virsh_ssh_t; 
   type_transition sge_job_t ssh_exec_t : process sge_job_ssh_t; 
   type_transition ajaxterm_t ssh_exec_t : process ajaxterm_ssh_t; 
   type_transition nx_server_t ssh_exec_t : process nx_server_ssh_t; 
   type_transition sysadm_t ssh_exec_t : process ssh_t; 
   type_transition staff_t ssh_exec_t : process ssh_t; 
   type_transition condor_startd_t ssh_exec_t : process condor_startd_ssh_t; 
   type_transition user_t ssh_exec_t : process ssh_t; 

Этот исполняемый файл выполняет разные переходы для разных предметов. Потому что мы знаем, что virsh_t должен выполнять в SSH только очень определенный набор вещей, он переходит в virsh_ssh_t для перехода, на который наложено больше ограничений, чем для тех, кто перешел бы в ssh_t.

Я добавил довольно длинный ответ на тему переходов ниже, чтобы люди могли понять, какие проблемы пытается решить SELinux и как он пытается их решить.

Перемещение между пользователями в DAC (Unix) и MAC / TE (SELinux)

Давайте определим некоторые термины, чтобы это имело смысл.

• Тема: Актер, который манипулирует элементами в системе. Обычно это пользователь или процесс.
• Объект: предмет, над которым действуют. Может быть много вещей (файл, каталог, порт)
• Переход: акт превращения одного объекта в другой.

Прежде чем мы ответим, как это делается в принудительном применении типа SELinux, подумайте, как бы вы это сделали в DAC (дискреционный контроль доступа; стандартная модель безопасности UNIX).

Как это работает в модели безопасности Unix

В DAC тема - это в первую очередь UID, но GID и дополнительные GID также определяют предмет. Объекты являются файлами, каталогами, сокетами unix и в основном упоминаются по их путям (хотя существуют некоторые исключения, такие как разделяемая память IPC).

Обычно при запуске программы - нет переход. Пользователь jim хочет бежать /bin/cat. Когда он это делает, процесс создается и наследует объект jim вместе с любыми другими свойствами его предмета (GID, дополнительные группы и т. д.).

Однако есть некоторые программы, которые при запуске выполняют переход. Когда пользователь jim управляет passwd команда jim переходит в root, что, конечно же, необходимо для внесения изменений в теневой файл.

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

Итак, для ясности в passwd пример jim становится root потому что режим разрешений - 4755, а владелец - root.

Итак, setuid выполняет переход в стандартной модели управления доступом unix.

К сожалению, у программ setuid ужасная история проблем с безопасностью. Это связано с ограничениями модели безопасности DAC, когда речь идет о том, как оцениваются переходы.

Процесс перехода setuid не выполняет проверку субъекта (пользователя), запускающего программу. Обе jim и betty перейдет к root вместе с apache, mysql и nobody если они призывают passwd.

Невозможно (без проверки самой программы, а мы все знаем, насколько она надежна) сделать так, чтобы когда jim звонки passwd он переходит к root но если betty вызывает passwd, чтобы он не переходил на root. Единственное, что вы могли сделать, это прямо отрицать betty от звонка passwd в первую очередь с использованием списков ACL POSIX, но это не детализировано.

Также невозможно (без приложения, выполняющего это и имеющего на это права), чтобы владельцем файла был кто-то другой, кроме человека, к которому вы хотите перейти. Так betty не может бегать passwd и стань пользователем bin вместо того root.

Как это работает в модели безопасности SELinux

В тема в selinux обозначается типом метки, в которой выполняется пользователь или процесс. Это может быть user_t, unconfined_t или httpd_t например.

Объекты - это файлы, каталоги, сокеты и т. д., как и в DAC, они также упоминаются по их типу и имеют метки. httpd_exec_t, user_home_t и mysql_port_t являются примерами различных меток объектов, которые использует SELinux.

В обычных условиях, как и в DAC, перехода не происходит. Если user_t выполняет /bin/cat (или так, как это видит SELinux, если user_t выполняет bin_t объект), он создается и наследует субъект user_t от звонящего.

Однако при вызове некоторых программ происходит переход. Если user_t выполняет объект с меткой passwd_exec_t (который /bin/passwd неудивительно) он переходит в passwd_t.

Это определено в правиле перехода типа, которое в политике выглядит так:

type_transition user_t passwd_exec_t:process passwd_t;

В SELinux для перехода выполняется следующая оценка.

• Кто хочет перейти (user_t)?
• К какому объекту идет ссылка (passwd_exec_t)?
• Какой новой темой хочет стать старая тема (passwd_t)?

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

• httpd_t никогда не может стать passwd_t и впоследствии никогда не сможет получить доступ к теневому файлу.
• Мы можем дать Бетти guest_t субъект в SELinux, и она тоже никогда не станет passwd_t.

Собственно говоря, это еще не все, что оценивается. Перед тем, как разрешить переход, задается еще больше вопросов.

1. Находится ли субъект в роли, включающей цель, в которую нужно перейти?
2. Разрешено ли субъекту фактически выполнять passwd_exec_t файл с намерением перейти?
3. Разрешено ли кому-либо перейти в passwd_t путем выполнения файлового объекта с меткой passwd_exec_t?
4. Должны ли мы вообще делать это автоматически для user_t или должен user_t должны спросить явно к переходу?

Модель перехода SELinux: путь сильнее, дает лучшие оценки и гораздо более детализированный, чем модель DAC.

Большая часть возможностей SELinux заключается в имеющейся у вас модели сильного перехода. Поскольку вы можете быть очень конкретными в отношении условий того, кто кем будет, тогда вы можете сделать все, что вы переходите, очень конкретными разрешениями в зависимости от того, какова может быть функция субъекта.

Итак, чтобы ответить на ваш исходный вопрос - ответ зависит от того, что вы хотите делать и кто вы хотите это делать.