From owner-freebsd-hackers Thu Oct 17 23:10:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA28750 for hackers-outgoing; Thu, 17 Oct 1996 23:10:49 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA28738; Thu, 17 Oct 1996 23:10:46 -0700 (PDT) Message-Id: <199610180610.XAA28738@freefall.freebsd.org> To: Karl Denninger cc: jdp@polstra.com, ache@nagual.ru, guido@gvr.win.tue.nl, thorpej@nas.nasa.gov, phk@critter.tfs.com, 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 00:42:18 CDT." <199610180542.AAA11030@Jupiter.Mcs.Net> Date: Thu, 17 Oct 1996 23:10:46 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Did you miss a portion of this thread? I think that Jason already >> addressed all of these issues. > >I don't think so. Please enlighten me. How civil. >> The program can core dump, the core dump will simply only be readable >> by root. > >IMHO, and sorry for being blunt, but that's a crock. So now you're going >to drop a core file in a user's directory that's root and mode 700 -- >regardless of how umask is set, etc? In either case, the core dump lands where it lands. If the user gets upset about this file sitting in their home directory, maybe he/she will even tell you about it so that you can determine the cause of the core dump. If they don't want to tell you, they can still remove it since they own the directory. Remeber that the core dump happens in the current working directory or the process, so its not guaranteed that the core dump will happen there. >Its better to not have the problem in the first place. Sure, core dumps should be rare. When a core dump occurs, do you think your paying customers should diagnose and fix the problem? I would expect the system administrators to fix problems with system utilities. >> There are already protections enforced to disallow non-priveledged users >> from ptracing programs that are setuid/setgid. > >A program which calls setuid() isn't SUID any more. Once done, that's >terminal (and can't be "recalled"). The saved UID is not perterbed which allows you to determine that the program was setuid. >The problem here is that authentication data must be able to be *known* >destroyed in the data segment BEFORE a non-privileged user can get to the >image of the data segment via any means -- ptrace, procfs, core dumps, >etc. > >If you do that, you get rid of the entire problem -- and if done in the >libraries its not just ftpd that this fixes. Which is what is accomplished, just in this case its by the kernel (where security should be enforced) not by a library. >What's the objection to clearing possibly-contaminated structures when a >program signifies its done with a privileged resource? It causes any db client to pay this penalty regardless of what is stored in the database. That is bad design. >-- >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! -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================