FreeIPA HBAC, sudo, and SELinux: Why a Service Account Cannot Restart the App
You manage 1,200 users and 60 RHEL 9 hosts with FreeIPA, SSSD, centralized HBAC and sudo rules, and SELinux enforcing. A monitoring service account, svc-mon, must SSH to application hosts and run systemctl restart app without a shell. It must also read /var/log/app through an NFSv4 mount using sec=krb5p. An HBAC rule allows svc-mon to use sshd on the app-servers host group. A sudo rule allows /usr/bin/systemctl restart app as root without a password. From one subnet, SSH succeeds but sudo returns 'command not allowed'. From a second subnet, SSH itself is denied. On a working host, the audit log also shows an SELinux denial involving systemd. The NFS mount returns permission denied for svc-mon even though a POSIX ACL grants read access. Local accounts are prohibited, and SELinux must remain enforcing.
1. Explain the order in which you would diagnose the SSH and sudo failures, and identify the most likely causes.
Read the worked answer
Work outward from authentication to authorization to mandatory access control. For the subnet where SSH fails, check DNS resolution and the client IP seen by the host, then inspect the HBAC rule's source-host and target-host categories. The account may be allowed on the app-servers host group but the failing subnet's hosts may not be members, or the rule may include a source-host restriction. Check SSSD logs and cache on a failing host, expire the cache with sssctl cache-expire, and confirm the host's keytab and Kerberos ticket. Also verify sshd's AllowGroups or AllowUsers, PAM, and the HBAC service name for sshd.
On hosts where SSH works but sudo is denied, use sudo -l as svc-mon and compare the resulting command specification with the FreeIPA sudo rule. Sudo command matching is exact about path and arguments; /usr/bin/systemctl restart app may not match systemctl restart app.service, a different path, or a shell invocation. Check whether the sudo rule applies to the correct host group and whether SSSD's sudo cache is stale. The SELinux denial occurs after sudo authorization, so resolve sudo first, then use ausearch -m avc and sealert to analyze the systemd denial.
2. The NFSv4 mount with `sec=krb5p` denies `svc-mon` despite a POSIX ACL. What do you check, and how do you fix it with least privilege?
Read the worked answer
sec=krb5p authenticates with Kerberos and adds integrity and privacy; a POSIX ACL is irrelevant if the client cannot obtain or present a valid Kerberos credential for the NFS service. On the client, check klist, the service account's keytab, rpc.gssd, gssproxy, and nfsidmap. Confirm the export includes sec=krb5p, the mount uses the same security flavor, and the server has a service principal for nfs/<server>. Look for SELinux denials on the NFS mount and incorrect labels on the exported path.
For least privilege, create a dedicated service principal for svc-mon rather than sharing a human account, store its keytab with restricted permissions, and use gssproxy with a constrained credential store so the account does not need an interactive kinit. Export the log path read-only for that principal if possible, keep root_squash, and avoid granting broader NFS access. Validate with sudo -u svc-mon or the service manager context, then test that reads succeed and writes fail. Do not fall back to sec=sys to make it work; that would remove Kerberos protection from the log data.
3. How would you validate that the final design enforces least privilege without breaking the monitoring automation?
Read the worked answer
Build a test matrix that covers each control independently: SSH from both subnets, HBAC allow and deny cases, sudo for the exact unit and for a near-miss command, SELinux enforcing, and NFS read versus write. Use sudo -l and an actual non-interactive invocation as the service account, and confirm that systemctl restart app.service succeeds while systemctl restart other fails. Check ausearch for denials during the successful path; a working command should not require a broad SELinux boolean or a permissive domain. For NFS, verify the Kerberos ticket and mount flavor, then test that the account can read the log path and cannot write it.
Keep the policy in FreeIPA rather than adding local sudoers or SELinux overrides. Use configuration management to test HBAC and sudo rules in a staging host group before production. Monitor SSSD, sudo, and AVC denials centrally so that a future rule drift is visible. If a denial appears, analyze it and write a narrow policy or use a targeted boolean; never disable SELinux or grant full sudo to make automation pass.