Replace the commented-out matchwhitelist entry for ssh-agent with an
explicit permission entry (755) for /usr/bin/ssh-agent.
When ssh-agent's matchwhitelist entry was commented out in commit
7a5f8b87af, permission-hardener began resetting it to restrictive
defaults (744), preventing non-root users from executing ssh-agent. This
broke split SSH functionality in Qubes OS for me because I was using
Kicksecure in the vault qube, and ssh-agent runs under a non-root user in
that configuration (see https://forum.qubes-os.org/t/split-ssh/19060).
As noted in the comment, Debian installs with 2755 permissions as a way
to mitigate ptrace attacks, but this rationale doesn't apply due to
kernel.yama.ptrace_scope=2 being set in Kicksecure.
For root, faillock appears to always* return an empty string (i.e. no table headers are present), yielding a zero-initialized pam_faillock_output_count and thus resulting in the calculation of a negative failed_login_counter value.
This can cause erroneous errors of the form "ERROR: Login blocked after [negative number] attempts" during sudo-ing and screen unlocking.
This commit modifies the initialization of failed_login_counter such that it cannot be negative and prevents the display of these incorrect warnings.
* Only rudimentary local tests were conducted
For root, faillock appears to always* return an empty string (i.e. no table headers are present), yielding a zero-initialized pam_faillock_output_count and thus resulting in the calculation of a negative failed_login_counter value.
This can cause erroneous errors of the form "ERROR: Login blocked after [negative number] attempts" during sudo-ing and screen unlocking.
This commit modifies the initialization of failed_login_counter such that it cannot be negative and prevents the display of these incorrect warnings.
* Only rudimentary tests were conducted
