Security Errors That Look Like Application Errors
The trickiest Linux security errors are the ones that look like routine application failures. SELinux denies a file read, the application sees “Permission denied” with no further context. A firewall blocks a packet, the connection times out. A certificate expires at midnight and every TLS connection fails the next morning. The ten errors below are common security-related issues and how to recognize them.
#091 SELinux AVC denial
Description: Application gets “Permission denied” even though file ownership/perms look correct.
Solution: ausearch -m AVC --ts recent shows the denial; audit2allow generates a policy rule to allow it; restorecon -Rv /path resets file context to default; setsebool -P httpd_can_network_connect on for common booleans.
#092 AppArmor: profile DENIED
Solution: journalctl --since today | grep apparmor; toggle to complain mode for diagnosis: aa-complain /path/to/profile; rebuild profile: aa-genprof /usr/bin/app.
#093 SSL/TLS certificate expired
Solution: openssl x509 -enddate -noout -in cert.pem; if Let’s Encrypt, check certbot renew --dry-run; check the certbot-renew.timer on the server. CA bundle outdated: update-ca-certificates.
#094 firewall-cmd / iptables blocks expected traffic
Solution: firewall-cmd --list-all; iptables -L -nv — the counter columns reveal traffic that’s being blocked vs absent; nft list ruleset on nftables systems.
#095 fail2ban banned IP
Solution: fail2ban-client status sshd shows banned IPs; fail2ban-client set sshd unbanip X.X.X.X; tune jail.local bantime/findtime/maxretry.
#096 SSH brute force attack in progress
Solution: Disable password auth (PasswordAuthentication no); restrict to keys; install fail2ban; consider port-knocking or moving SSH off 22; never PermitRootLogin yes.
#097 sudo timeout passing in scripts
Description: Long-running script fails partway when sudo’s 5-minute credential cache expires.
Solution: Use NOPASSWD for the specific commands in /etc/sudoers.d/; or use a systemd unit running as the right user.
#098 chrome/firefox: NET::ERR_CERT_REVOKED
Solution: Cert was revoked by the CA. Issue a new cert. Test OCSP with openssl ocsp.
#099 audit log full
Description: auditd can’t write more events; system may halt or refuse logins depending on config.
Solution: auditctl -s; rotate /var/log/audit/audit.log; tune audit.rules to log less; or set disk_full_action = SUSPEND in auditd.conf.
#100 GPG signature verification failed
Solution: Public key not in keyring; gpg --recv-keys KEYID; verify the key’s fingerprint matches the source you trust.
Conclusion
- SELinux/AppArmor denials look like ordinary permission errors.
ausearch -m AVCalways when chmod looks fine. - Cert renewal automation (
certbot renewvia timer) is the only way to stop expiry incidents. iptables -L -nv— the counter columns are the diagnostic.- Disable password SSH on every Internet-facing host. Keys only.
- fail2ban is great until it bans your colleague’s static IP.
ignoreipfor known good sources.
Related Linux Admin articles
- Linux Authentication Errors — for PAM and sudo issues
- Linux File Permissions — the underlying chmod/chown model
- Linux Networking Errors — when a firewall is the actual cause