Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jul 1999 21:50:55 -0700 (PDT)
From:      <jkoshy@FreeBSD.org>
To:        Nate Williams <nate@mt.sri.com>
Cc:        freebsd-hackers@freebsd.org, jkoshy@freebsd.org
Subject:   Re: deny ktrace without read permissions? 
Message-ID:  <199907260450.VAA10559@freefall.freebsd.org>
In-Reply-To: Your message of "Sat, 24 Jul 1999 11:24:39 CST." <199907241724.LAA13835@mt.sri.com> 

next in thread | previous in thread | raw e-mail | index | archive | help


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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907260450.VAA10559>