jk> The intent of this change is to prevent a user from seeing how an jk> executable with '--x--x--x' perms works by ktrace'ing its execution.
jk> My question to -hackers is: is this a useful semantic? Would it break jk> anything if added? nw> If we make kernel auditing based upon KTRACE (which may or may not nw> happen), this is not a useful change since we need to be able to 'audit' nw> system calls regardless of whether or not KTRACE is used. If this kind This particular change should not affect the future auditing tool. The [execve] system call will still be logged as having been attempted; the control flow remains the same as for the current ``no execute perms'' case but with a stricter check if KTRACE'ing is on for the process. nw> If security is an issue, KTRACE shouldn't be in the system. Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). Part of the confusion comes from the meaning of the 'x' bit when KTRACE'ing is also permitted. Ordinarily the 'x' bit determines if a user can execute a file. But should execute permissions also imply the ability to trace the execution of the process? If so, the value of a permission mask like '--x--x--x' is weakened because although you cannot read the file, you can 'see inside' it, indirectly. The PR proposes (and the patch given earlier implements) tighter security on the premise that security in the presence of KTRACE should be at least as tight as without KTRACE. It achieves this by requiring read permissions on an executable before it can be KTRACE'd. Regards, Koshy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
