Change from exactwhitelist to matchwhitelist. Discussion revealed that
there's a good reason to leave setgid in here, which is essentially
defense-in-depth (sometimes users may want to revert Kicksecure's
default of kernel.yama.ptrace_scope=2, e.g. to debug a program, and
Kicksecure should not be less secure than vanilla Debian in that
situation).
Replace subprocess grep calls with bash substring matching in
check_nosuid_whitelist function. This eliminates ~10k unneeded
subprocess spawns that were causing significant performance
degradation.
In testing, it improves overall script execution speed by an
order of magnitude:
Before patch:
$ sudo hyperfine -- './permission-hardener enable'
Benchmark 1: ./permission-hardener enable
Time (mean ± σ): 11.906 s ± 0.974 s [User: 3.639 s, System: 8.728 s]
Range (min … max): 10.430 s … 14.090 s 10 runs
After patch:
$ sudo hyperfine -- './permission-hardener enable'
Benchmark 1: ./permission-hardener enable
Time (mean ± σ): 802.8 ms ± 178.5 ms [User: 283.0 ms, System: 471.9 ms]
Range (min … max): 639.4 ms … 1092.3 ms 10 runs
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
