From owner-freebsd-hackers Mon Jul 26 9: 6:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BA40D14E1C; Mon, 26 Jul 1999 09:05:50 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA27598; Mon, 26 Jul 1999 10:04:55 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA18839; Mon, 26 Jul 1999 10:04:54 -0600 Date: Mon, 26 Jul 1999 10:04:54 -0600 Message-Id: <199907261604.KAA18839@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jkoshy@FreeBSD.org Cc: Nate Williams , freebsd-hackers@FreeBSD.org Subject: Re: deny ktrace without read permissions? In-Reply-To: <199907260450.VAA10559@freefall.freebsd.org> References: <199907241724.LAA13835@mt.sri.com> <199907260450.VAA10559@freefall.freebsd.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message