script_matches: don't report a match when the interpreter differs

[iefa-m]

With intercept_verify, ptrace_verify_post_exec() compares the program that actually started against the command the policy approved. When the approved command is a #! script, execve_args_match() calls script_matches() to accept the script's interpreter instead. But if the interpreter does not match the real executable and the nested-interpreter case doesn't apply, script_matches() falls through to the success path and returns 1, so execve_args_match() skips argv[0] and compares only the rest of argv and the environment. A traced process that swaps the execve path after the policy check (the race intercept_verify is meant to catch) can therefore run any binary as the runas user with argv x /path/to/approved.sh args... and verification still passes. The "can't open" / "not a script" / interpreter argument failures on a nested level returned a non-zero skip the same way.

Treat an interpreter mismatch as a failure and only return a skip count once the whole #! chain has matched. I checked this on Linux by calling execve_args_match() from the real exec_ptrace.c (the test_ptrace.c include trick): with /tmp/allowed.sh (#!/bin/sh) approved, /usr/bin/id with argv x /tmp/allowed.sh arg was accepted before and is rejected now. The same holds for #!/bin/sh -e and for a nested #!/tmp/inner.sh script, while the legitimate /bin/sh /tmp/allowed.sh arg, /bin/sh -e ... and /bin/sh inner.sh outer.sh arg forms still match.

[millert]

Looks correct, thanks!