> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
