From owner-freebsd-hackers Fri Oct 18 09:57:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07370 for hackers-outgoing; Fri, 18 Oct 1996 09:57:39 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA07332 for ; Fri, 18 Oct 1996 09:57:06 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id LAA24197; Fri, 18 Oct 1996 11:57:04 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 18 Oct 96 11:56 CDT Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.Beta.6/8.8.Beta.3) id LAA26366; Fri, 18 Oct 1996 11:56:58 -0500 (CDT) From: Karl Denninger Message-Id: <199610181656.LAA26366@Jupiter.Mcs.Net> Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c To: dg@Root.COM Date: Fri, 18 Oct 1996 11:56:57 -0500 (CDT) Cc: gritton@byu.edu, freebsd-hackers@freebsd.org, tech-userlevel@NetBSD.ORG In-Reply-To: <199610181604.JAA14869@root.com> from "David Greenman" at Oct 18, 96 09:04:58 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text 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 I respectfully disagree. It is one thing to be responsible for data under your control (anything you allocate on the stack or in the data segment). It is another to try to force people to be responsible for data which is under the control of the *system*, when the data types involved are opaque. If you're arguing for no core dumps of anything which could contain sensitive data, then the bottom line is that you have to decline any of the following: 1) ptrace() on any process which was STARTED Suid (not "currently is" SUID). This precludes debugging on a process in this state. 2) Any process which starts with the SUID or SGID bit on must internally decline to dump core (regardless of ulimit settings) at all times -- both while SUID and *IF SUID IS REVOKED BY THE JOB*. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed!