A systems administrator deployed a new custom application to a RHEL server. The application files are located in /srv/webapp. The administrator confirmed that standard file permissions are correct and allow execution. However, when attempting to start the application's service, it fails. Running the main binary directly as the root user also results in a "Permission denied" error. A check of the system's audit log reveals recent entries with type=AVC related to the application's binary. What is the MOST likely cause of this issue?
The application binary is missing the execute bit in its file system permissions.
The server's anti-malware software has incorrectly identified the binary as a threat and quarantined it.
The application binary is corrupt and cannot be loaded by the kernel.
The SELinux policy is preventing the application from executing due to an incorrect file context.
The correct answer is that the SELinux policy is preventing execution. The key indicator is the type=AVC (Access Vector Cache) denial message in the /var/log/audit/audit.log file. This type of log entry is specific to Security-Enhanced Linux (SELinux) and signifies that a security policy has denied an action. Even if traditional file permissions (Discretionary Access Control) are correct, SELinux enforces an additional layer of Mandatory Access Control (MAC) based on security contexts (labels). In this scenario, the application files were placed in a non-standard directory (/srv/webapp) and likely have an incorrect security context (e.g., default_t instead of httpd_sys_content_t), which the SELinux policy for the service does not permit it to execute.
The option suggesting incorrect file permissions is wrong because the scenario explicitly states that standard permissions were checked and are correct.
The anti-malware option is less likely because it would typically generate its own specific logs about quarantining or blocking a file, not an SELinux AVC denial.
A corrupt binary would usually result in a different error, such as a segmentation fault or an "Exec format error," not a "Permission denied" message, especially for the root user.