From owner-freebsd-current Mon Aug 11 10:11:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16806 for current-outgoing; Mon, 11 Aug 1997 10:11:01 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA16783; Mon, 11 Aug 1997 10:10:56 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id LAA13714; Mon, 11 Aug 1997 11:10:33 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA06171; Mon, 11 Aug 1997 11:10:03 -0600 (MDT) Date: Mon, 11 Aug 1997 11:10:02 -0600 (MDT) From: Marc Slemko To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >The program can change uids many times and finaly do allowed combination. > >But "interesting" code or data from previous superuser mode can still left > >in the memory. > > My patch is no different than the situation with core files. If a process > has your UID, you can make it dump core, and then examine its data. This is > an extensio of that. No you can't. BTDT. If a process has done a setuid() (well, more accurately if it has done a setuid() that has changed the uid) it will not dump core. ISTR that on Linux it took an awfully long time to get all the security holes out of procfs. Well, all of the more serious ones that have been found so far.