From owner-freebsd-hackers Fri Oct 18 09:04:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA03792 for hackers-outgoing; Fri, 18 Oct 1996 09:04:10 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA03785 for ; Fri, 18 Oct 1996 09:04:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id JAA14869; Fri, 18 Oct 1996 09:04:58 -0700 (PDT) Message-Id: <199610181604.JAA14869@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: gritton@byu.edu cc: freebsd-hackers@freebsd.org, tech-userlevel@NetBSD.ORG Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c In-reply-to: Your message of "Fri, 18 Oct 1996 08:47:06 MDT." <199610181447.IAA05206@saskatchewan.et.byu.edu> From: David Greenman Reply-To: dg@root.com Date: Fri, 18 Oct 1996 09:04:58 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Karl Denninger writes: > >> If there was a separate "destroy-data" call, that would be ok. But there >> isn't, and as such the ONLY way to have any security in these dbm routines >> is to have the system enforce it. > > Adding the call seems easy enough, and seems the most elegant solution. It doesn't solve the real problem. The problem is that applications that were privileged might read sensitive data and store it internally. The dbm routines are only one instance of the "store internally" problem. There are countless other cases where similar things could happen...even temporary garbage on the stack can be a problem. The ONLY solution is to not allow coredumps of processes that might contain sensitive data. The change that was made to hash_buf.c should be backed out and attempts should be made to ensure that the coredump won't happen in cases where sensitive data may be a problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project