From owner-freebsd-security Mon Aug 11 11:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA22835 for security-outgoing; Mon, 11 Aug 1997 11:52:47 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22815; Mon, 11 Aug 1997 11:52:40 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id WAA06268; Mon, 11 Aug 1997 22:52:25 +0400 (MSD) Date: Mon, 11 Aug 1997 22:52:23 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Sean Eric Fagan cc: FreeBSD-current , security@FreeBSD.ORG, Bruce Evans 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-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >Comparing uids gains absolutely nothing. > > Yes, it does: it makes it useful. Useful for what? Even if they are equal at the moment you check it not means that program was not setuided before your check and have secret data in memory. > >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. As I already write you, it is false in general case. If program was setuided, you can't make core from it even it runs with your UID currently. I don't see an extension here but old security hole (core-like one) reopening as I warn already. > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Now I like Bruce's idea that exec call should fail if procfs memory is open and setuid program is executed. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/