From owner-freebsd-security  Sun Aug 25 23:17:18 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA20496
          for security-outgoing; Sun, 25 Aug 1996 23:17:18 -0700 (PDT)
Received: from rover.village.org (rover.village.org [204.144.255.49])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA20491
          for <security@freebsd.org>; Sun, 25 Aug 1996 23:17:16 -0700 (PDT)
Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id AAA07366; Mon, 26 Aug 1996 00:17:08 -0600 (MDT)
Message-Id: <199608260617.AAA07366@rover.village.org>
To: Gene Stark <gene@starkhome.cs.sunysb.edu>
Subject: Re: Vulnerability in the Xt library (fwd) 
Cc: security@freebsd.org
In-reply-to: Your message of Mon, 26 Aug 1996 02:08:34 EDT
Date: Mon, 26 Aug 1996 00:17:08 -0600
From: Warner Losh <imp@village.org>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

: The text segment is set up by the kernel when the process starts.
: I don't think there are any system calls that allow it to be extended.

mprotect( addr, len, prot ) or mmap should do the trick :-(.  Prot ==
PROT_EXEC | PROT_READ should do the on freshly malloc'd memory, no?

Or are you saying that it must be in the text segment only.  That
would preclude shared libraries from having this functionality in
them, since they are mmap'd into the process space at image activation
by ld.so.  Since system calls live in libc, you'd not be able to use
this system call at all :-(.  I suppose that you can have ld.so do
some magic, but that would potentially preclude dlopen'd libraries
from calling this system call.

One way you could do this is to have a function call "Don't allow
setuid-ness to propigate" AND that's the only system call you get.
You can turn it off, but never turn it back on...  However, that
requires source changes :-(.

Warner