4

So I'm trying to start a service (let's call it the "kite agent" and it's a binary executable that runs as part of a tracing service) with systemd via ansible deployment on CentOS Linux release 8.2.2004.

This is the kite_agent.service file that systemd uses:

[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

The "/kite_agent" directory in the above .service file has the following permissions:

dr-x------. 2 kite kite unconfined_u:object_r:default_t:s0 117 Jul 21 10:42 kite_agent

The files inside "/kite_agent" have the following permissions (as described by 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

Am I right in thinking that the "/kite_agent" directory should have permissions with a "system_u" context such as:

kite kite system_u:object_r:default_t:s0

I'm seeing messages such as the below via 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

EDIT:

Including some more basic diagnostic information below:

Running systemctl status auditd yields:

● auditd.service Loaded: masked (Reason: Unit auditd.service is masked.) Active: inactive (dead)

Running cat /etc/audit/auditd.conf yields:

# # 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

Running audit2allow -a yields:

#============= ifconfig_t ============== allow ifconfig_t vmware_log_t:file write;

Running ausearch -m avc | grep kite yields nothing unfortunately.

Running systemctl status auditd yields:

● 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.
Improve this question
3
  • Did you restart the auditd daemon? This platform isn't really suited to walking you through step-by-step. It does presume upon doing some of your own research. What else have you tried that isn't written here? I don't really see how the audit2allow results you show are relevant. If the audit daemon isn't running at the time the kite agent fails to start, you can't be sure anything will return appropriate avc information. Commented Sep 15, 2020 at 15:09
  • Also you aren't answering ALL questions I've asked or indicating what you have tried ALL the suggestions. It gets pretty frustrating trying to help when responses do not indicate what all has been tried, etc. Please re-read the answer and address all details. We cannot help without adequate information and feedback. Commented Sep 15, 2020 at 15:21
  • Did you try the chcon / semanage suggestions? Figuring out what it broken on the system regarding auditd could indicate deeper issues bleeding over into multiple areas. How established is this system? Can you try all this on a relatively clean system so you can gain confidence in what to do on this system. Somewhere I read that if auditd isn't running, messages might go to rsyslog. Working without error reporting figured out kind of leaves one blind. Commented Sep 15, 2020 at 23:41

1 Answer 1

Reset to default
3

It is not at all surprising that SELinux stops a service from running from a directory that does not have contexts that indicate it is an authorized system service.

More than likely, the directory where the executable resides needs to have a context more like:

system_u:object_r:bin_t

Perhaps this might suffice:

# chcon -u system_u -r object_r -t bin_t /kite_agent

but posting the related messages from /var/log/audit/audit.log is recommended. Perhaps getting them is as simple as:

# grep kite /var/log.audit/audit.log

-or-

# ausearch -m avc | grep kite

If these commands are not effective, investigate the configuration and/or status of the audit service.

# systemctl status auditd # cat /etc/audit/auditd.conf

If the auditd service is dead, fix that issue. It may be as simple as:

# systemctl start auditd

With a relevant AVC message from the audit log, it is possible to use audit2allow to get suggestions on how to fix the issue from SELinux own perspective, but sometimes there are various suggestions.

https://opensource.com/article/18/7/sysadmin-guide-selinux offers a variety of concise tips on working with SELinux. From that page, the following may be of help in fixing a labeling problem (though some of the details were changed to anticipate the actual answer to this question). A caveat is that this snippet leaves off other parts of the context, so man semanage-fcontext is probably helpful too. :

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

Considering that /usr/sbin contains some other services this could be appropriate, but do be sure that it is:

# semanage fcontext -a -e /kite_agent /usr/sbin # restorecon -vR /kite_agent

The page also offers troubleshooting tips. Naturally, there are more detailed documents out there, particularly on RedHat or CentOS sites.

If the AVC details are added to the question, perhaps some more specific help could be forthcoming.

Improve this answer
7
  • So in my case I think the log is in /var/log/audit/audit.log, but "grep-ing" for kite doesn't yield any results...very odd... Commented Sep 14, 2020 at 22:24
  • I presume the results of getenforce is "Enforcing". I'm actually looking on my own CentOS 8 sytem at the moment. I've added some detail in the last few minutes. It might be worth looking back over the answer. Commented Sep 14, 2020 at 22:27
  • You can also just run "audit2allow -a" to see a list of various things to related to currently known SELinux blocks, but do not indiscriminately do everything it suggests since legitimately blocked issues may have contributed to the results. It is much preferred to find the specific AVC and analyze it specifically so as not to inadvertently authorize some malware from doing something evil. Commented Sep 14, 2020 at 22:36
  • Yes the result of getenforce is "Enforcing". Any idea why nothing about kite_service is being written to /var/log/audit/audit.log? I'm trying audit2allow -a now. Commented Sep 15, 2020 at 0:08
  • 1
    Yes, of course, SELinux is effectively disabled by setenforce 0. Did you try running ausearch -m avc? What is the output of systemctl status auditd? What is in /etc/audit/auditd.conf? Commented Sep 15, 2020 at 13:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.