![由于 unconfined_u 上下文,systemd 服务无法启动?](https://linux22.com/image/180190/%E7%94%B1%E4%BA%8E%20unconfined_u%20%E4%B8%8A%E4%B8%8B%E6%96%87%EF%BC%8Csystemd%20%E6%9C%8D%E5%8A%A1%E6%97%A0%E6%B3%95%E5%90%AF%E5%8A%A8%EF%BC%9F.png)
因此,我尝试在 CentOS Linux 8.2.2004 版本上通过 ansible 部署使用 systemd 启动一个服务(我们称之为“kite 代理”,它是一个作为跟踪服务的一部分运行的二进制可执行文件)。
这是 systemd 使用的 kite_agent.service 文件:
[Unit]
Description=kite_agent
After=network.target
[Service]
ExecStart=/kite_agent/kite-agent --config-file=/kite_agent/kite-agent.yml
Restart=always
StandardOutput=syslog
SyslogIdentifier=kite-agent
User=kite
Group=kite
[Install]
WantedBy=multi-user.target
上述.service文件中的“/kite_agent”目录具有以下权限:
dr-x------. 2 kite kite unconfined_u:object_r:default_t:s0 117 Jul 21 10:42 kite_agent
“/kite_agent”内的文件具有以下权限(如 所描述ls -laZ
):
dr-x------. 2 kite kite unconfined_u:object_r:default_t:s0 117 Jul 21 10:42 .
dr-xr-xr-x. 19 root root system_u:object_r:root_t:s0 256 Jul 21 10:41 ..
-r--------. 1 kite kite system_u:object_r:default_t:s0 1769 Jul 21 10:42 agent.cert
-rw-r--r--. 1 root root system_u:object_r:default_t:s0 1582 Jul 21 10:42 agent.csr
-r--------. 1 kite kite system_u:object_r:default_t:s0 3243 Jul 21 10:42 agent.key
-rwxrwxrwx. 1 kite kite system_u:object_r:default_t:s0 1696 Jul 21 10:42 ca.cert
-r-xr-xr-x. 1 kite kite system_u:object_r:default_t:s0 25956781 Jul 21 10:41 kite-agent
-r-xr-xr-x. 1 kite kite system_u:object_r:default_t:s0 256 Jul 21 10:42 kite-agent.yml
我是否正确地认为“/kite_agent”目录应该具有“system_u”上下文的权限,例如:
kite kite system_u:object_r:default_t:s0
我通过 Journalctl 看到如下消息:
kite_agent.service: Failed at step EXEC spawning /kite_agent/kite-agent: Permission denied
kite_agent.service: Main process exited, code=exited, status=203/EXEC
编辑:
包括以下一些更基本的诊断信息:
运行systemctl status auditd
收益:
● auditd.service
Loaded: masked (Reason: Unit auditd.service is masked.)
Active: inactive (dead)
运行cat /etc/audit/auditd.conf
收益:
#
# Controls the configuration of the audit daemon
#
local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = root
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 8
num_logs = 5
priority_boost = 4
name_format = NONE
##name = mydomain
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
verify_email = yes
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
use_libwrap = yes
##tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
transport = TCP
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
distribute_network = no
q_depth = 400
overflow_action = SYSLOG
max_restarts = 10
plugin_dir = /etc/audit/plugins.d
运行audit2allow -a
收益:
#============= ifconfig_t ==============
allow ifconfig_t vmware_log_t:file write;
不幸的是,跑步ausearch -m avc | grep kite
没有任何结果。
运行systemctl status auditd
收益:
● auditd.service - Security Auditing Service
Loaded: loaded (/etc/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-09-15 16:03:04 CDT; 6min ago
Docs: man:auditd(8)
https://people.redhat.com/sgrubb/audit/
Process: 157748 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Process: 157747 ExecStart=/sbin/auditd -n (code=exited, status=1/FAILURE)
Main PID: 157747 (code=exited, status=1/FAILURE)
Sep 15 16:03:04 my_app augenrules[157748]: enabled 1
Sep 15 16:03:04 my_app augenrules[157748]: failure 1
Sep 15 16:03:04 my_app augenrules[157748]: pid 2094
Sep 15 16:03:04 my_app augenrules[157748]: rate_limit 0
Sep 15 16:03:04 my_app augenrules[157748]: backlog_limit 8192
Sep 15 16:03:04 my_app augenrules[157748]: lost 0
Sep 15 16:03:04 my_app augenrules[157748]: backlog 0
Sep 15 16:03:04 my_app augenrules[157748]: backlog_wait_time 60000
Sep 15 16:03:04 my_app systemd[1]: auditd.service: Failed with result 'exit-code'.
Sep 15 16:03:04 my_app systemd[1]: Failed to start Security Auditing Service.
答案1
毫不奇怪,SELinux 会阻止某个服务从没有上下文表明该服务是授权系统服务的目录中运行。
可执行文件所在的目录很可能需要有一个类似于以下内容的上下文:
system_u:object_r:bin_t
也许这就足够了:
# chcon -u system_u -r object_r -t bin_t /kite_agent
/var/log/audit/audit.log
但建议发布相关消息。也许获得它们就像这样简单:
# grep kite /var/log.audit/audit.log
-或者-
# ausearch -m avc | grep kite
如果这些命令无效,请调查审核服务的配置和/或状态。
# systemctl status auditd
# cat /etc/audit/auditd.conf
如果auditd
服务停止运行,请修复该问题。它可能很简单:
# systemctl start auditd
通过审计日志中的相关 AVC 消息,可以用来audit2allow
从 SELinux 自身的角度获取如何解决问题的建议,但有时会有不同的建议。
https://opensource.com/article/18/7/sysadmin-guide-selinux提供了有关使用 SELinux 的各种简明技巧。从该页面开始,以下内容可能有助于解决标签问题(尽管更改了一些细节以预测此问题的实际答案)。需要注意的是,该片段忽略了上下文的其他部分,因此man semanage-fcontext
可能也有帮助。 :
Labeling problem: If your files in /kite_agent are not labeled correctly, access might be denied. Here are some ways to fix this:
If you know the label:
# semanage fcontext -a -t bin_t '/kite_agent(/.*)?'
If you know the file with the equivalent labeling:
# semanage fcontext -a -e /kite_agent /path/to/dir
Restore the context (for both cases):
# restorecon -vR /kite_agent
考虑到/usr/sbin
包含一些其他服务,这可能是合适的,但请确保它是:
# semanage fcontext -a -e /kite_agent /usr/sbin
# restorecon -vR /kite_agent
该页面还提供故障排除提示。当然,有更详细的文档,特别是在 RedHat 或 CentOS 站点上。
如果将 AVC 详细信息添加到问题中,也许会提供一些更具体的帮助。