From owner-freebsd-security  Mon Aug 11 08:41:15 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA10716
          for security-outgoing; Mon, 11 Aug 1997 08:41:15 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10711;
          Mon, 11 Aug 1997 08:41:08 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA18095; Tue, 12 Aug 1997 01:36:41 +1000
Date: Tue, 12 Aug 1997 01:36:41 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199708111536.BAA18095@godzilla.zeta.org.au>
To: ache@nagual.pp.ru, sef@FreeBSD.ORG
Subject: Re: procfs patch
Cc: current@FreeBSD.ORG, security@FreeBSD.ORG
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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

Just close the procfs file descriptors on exec?

>We also need some solution which
>completely disable access to parent memory from forked child because
>allowing it is against Unix ideology.

But it is exactly what rfork() provides.  Unix ideology is that file
descriptors are not affected on exec unless this is asked for.  The
rfork fd sharing fix is wrong, and closing procfs file descriptors
would be wrong.  The exec should fail instead if it would cause a
security hole.

Bruce