Если 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 . 1237] Итак, 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 , unlimited_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 .

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