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.
#91 – 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.
#92 – AppArmor: profile DENIED
Description: Application call fails because AppArmor blocked it; the journal logs 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.
#93 – SSL/TLS certificate expired
Description: Clients refuse to connect because the server certificate is past its notAfter date.
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.
#94 – firewall-cmd / iptables blocks expected traffic
Description: Connections that should work time out because a firewall rule is dropping them.
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.
#95 – fail2ban banned IP
Description: A legitimate user can’t SSH in because fail2ban added their IP to the deny list.
Solution: fail2ban-client status sshd shows banned IPs; fail2ban-client set sshd unbanip X.X.X.X; tune jail.local bantime/findtime/maxretry.
#96 – SSH brute force attack in progress
Description: auth.log is filling with thousands of failed logins from random IPs.
Solution: Disable password auth (PasswordAuthentication no); restrict to keys; install fail2ban; consider port-knocking or moving SSH off 22; never PermitRootLogin yes.
#97 – 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.
#98 – chrome/firefox: NET::ERR_CERT_REVOKED
Description: Browsers refuse to load the site because the cert has been revoked by the CA.
Solution: Cert was revoked by the CA. Issue a new cert. Test OCSP with openssl ocsp.
#99 – 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
Description: gpg --verify rejects a download because the signing key isn’t trusted or is missing.
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.