From owner-freebsd-hackers Sun Oct 20 00:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA12956 for hackers-outgoing; Sun, 20 Oct 1996 00:20:41 -0700 (PDT) Received: from ux2.sp.cs.cmu.edu (UX2.SP.CS.CMU.EDU [128.2.198.102]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA12941 for ; Sun, 20 Oct 1996 00:20:30 -0700 (PDT) Received: from localhost by ux2.sp.cs.cmu.edu id aa20401; 20 Oct 96 3:19 EDT To: Poul-Henning Kamp cc: "Charles M. Hannum" , tech-userlevel@netbsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: setuid, core dumps, ftpd, and DB In-reply-to: Your message of "Sun, 20 Oct 1996 08:40:24 +0200." <22293.845793624@critter.tfs.com> Date: Sun, 20 Oct 1996 03:19:12 -0400 Message-ID: <20396.845795952@ux2.sp.cs.cmu.edu> From: Chris G Demetriou Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ Charles, please read to the bottom of this... 8-] > It was pointed out by me already 8 years ago: > > "[...] core-dumps as default is an evil thing. There should be > some way to >enable< core-dumps when you want them, rather than > have them as default. This would also solve security issue > where a core-dump may contain sensitive information. [...]" > > What we need is really a new syscall: > > procctl(pid, function, arg) > [ ... ] I disagree. (1) that means that people writing and debugging programs can no longer as easily get core dumps to help them debug. (They have to add a system call, and a non-standard one at that, to enabled core dump functionality.) (2) that means that non-repeatable crashes, especially of 'standard' system utilities, will be almost impossible to track down, unless you globally enable core dumps or enable core dumps for individual system utilties (thus defeating the purpose, either completely or partially, of your proposed change). It also means that Joe Bob, a random user, can't say "cat dumped core on me, here's the core, what happened?" to people attempting to support his use of the system. (3) It's different from other UNIX systems. Given (1) and (3), i.e. the traditional and 'normal' UNIX program behaviour that developers expect to see, making a change like this is developer-hostile. (2) would be a pain in _my_ butt, for one, because (on NetBSD/Alpha) core dumps of random utilities are still too common (damn stupid programmers, long != 32 bits!!!), and i end up doing "enough" core groveling... Charles, re: "is a core dump on this weird file system safe"? Actually, a good solution there might be a "NOCOREDUMP" mount flag, a la NOSUID and NOEXEC. That has several advantages: (1) Configurability of security policy: The system manager knows if the remote file system is "safe," and can do the right thing. Even disregarding AFS, think of the case of NFS over a potentially snooped net. (Sure, you could be losing badly there anyway, but simple snooping is harder to notice than packet forgery, in most cases.) (2) File system lossage prevention: ever dump a 10M core to AFS? On several AFS ports, that'll hang AFS. This provides a common-case workaround. (3) it's easy to implement. It's not a general, fail-safe solution to the problem, but I don't think the thought shouldn't be discarded out of hand. I'd say that it'd solve the problems that most people need solved, if they care enough to set the flag. chris