From owner-freebsd-security  Mon Aug 11 08:21:40 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA09436
          for security-outgoing; Mon, 11 Aug 1997 08:21:40 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA09428;
          Mon, 11 Aug 1997 08:21:35 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA07362; Mon, 11 Aug 1997 08:21:25 -0700
Date: Mon, 11 Aug 1997 08:21:25 -0700
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <199708111521.IAA07362@kithrup.com>
To: ache@nagual.pp.ru, current@freebsd.org, security@freebsd.org
Subject: Re: procfs patch
Sender: owner-freebsd-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Comparing uids gains absolutely nothing.

Yes, it does:  it makes it useful.

Tell me:  how many applications do *you* have that use procfs?

>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.

>I think any access to memory must be disallowed immediately after exec of
>setuid program issued by user (not setuid root) program. I.e. exec call
>must set some flag (in struct proc?) disabling procfs access and procfs
>call need to check this flag only.

Gosh, that's what I had originally, and everyone didn't like *that*.
(Frankly, neither did I.)

Sean.