> 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 future audting tools may depend on KTRACE. > 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. Right, but the system requires KTRACE as a pre-requisite for IDS, therefore we've changed the behavior of the system by adding IDS (which brings in KTRACE as a side-effect). What once was considered 'ok' previously is now not OK when IDS is added (exec'ing binaries that don't have the read permission on them..) > 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 :). Naw. You have to reverse engineer the entire piece of code to figure out what it's doing. Knowing the syscalls is not giving you a whole lot of information. > 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? Because 'execution' is almost the same thing as 'trace' (you can't have one w/out the other), then yes. > 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. Very indirectly. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
