From owner-freebsd-security Wed Feb 19 05:37:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22704 for security-outgoing; Wed, 19 Feb 1997 05:37:08 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA22694 for ; Wed, 19 Feb 1997 05:37:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id FAA12198; Wed, 19 Feb 1997 05:37:20 -0800 (PST) Message-Id: <199702191337.FAA12198@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Wed, 19 Feb 1997 16:20:07 +0300." <199702191320.QAA11111@magrathea.chance.ru> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 05:37:20 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >for any data stored in 'hash' dbm format. And, certainly, it _helped_ >against *fptd/rlogin/screen vulnerabilities and didn't broke anything It breaks performance when you have to zero out every bit of information you get from a database. People might actually want their .db programs to run *fast*, and this isn't a way to acheive that. >> you could still get it to coredump prior to it having a chance to zero >> everything out). >Why, it would be unwise of it to close data base before dropping root >privileges (and in this case it will be impossible at all), and I won't be >able to send any signal to it unless it drops privileges. The case when it A process running with set*id privileges doesn't mean that it can't receive signals while it has them effective. In fact it can, the only requirement is that the real uid of the process and the uid of the process sending the signal be the same, and they will be in either case. >> The only "correct" solution is to not allow processes with potentially >> sensitive data (setuid, setgid) to coredump in the first place. >You should also remember processes started as root and used set*id() to >drop privileges, such as ftpd. Anything that does a seteuid will have the P_SUGID flag set internally, and thus coredumps are prevented. If the process starts out as root and doesn't issue any set*id calls, then the corefile will be owned by root with no access to anyone...so there isn't a vulnerability in either case. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project