From owner-freebsd-hackers  Thu Jan  2 02:42:15 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id CAA27811
          for hackers-outgoing; Thu, 2 Jan 1997 02:42:15 -0800 (PST)
Received: from profane.iq.org (profane.iq.org [203.4.184.217])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA27800
          for <hackers@freebsd.org>; Thu, 2 Jan 1997 02:42:01 -0800 (PST)
Received: (from proff@localhost)
          by profane.iq.org (8.8.4/8.8.2) id VAA11426
          for hackers@freebsd.org; Thu, 2 Jan 1997 21:41:37 +1100 (EST)
From: Julian Assange <proff@iq.org>
Message-Id: <199701021041.VAA11426@profane.iq.org>
Subject: file locking / firewalling based on uid/gid
In-Reply-To: <199701020710.CAA09967@skynet.ctr.columbia.edu> from Bill Paul at "Jan 2, 97 02:10:22 am"
To: hackers@freebsd.org
Date: Thu, 2 Jan 1997 21:41:37 +1100 (EST)
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> I have a question.
> 
> Say you have the following series of events:
> 
> - A process creates a socket.
>   o You now have a struct socket.
>   o You also have a struct file that references the socket, and that
>     points to the ucred of the process.
> 
> - The process forks.
>   o Now the child and the parent refer to the same socket.
> 
> - The child does a setuid() to some other UID.
>   o You still only have one socket.
> 
> What happens now? You have one socket referenced by two proccesses
> with different credentials (I think -- not sure what happens to the
> credentials in inherited descriptors when a process does a setuid()). 

Looked at this. You retain pointers to the original credentials.
This is the probably way you want things to be, because of situations
like:

	inetd(root,socket) -> rsh(user)

Where by you want root to be able to accept/make connections on behalf
of users that do not have such an ability.

What is interesting about the inetd situation, is that without introducing
an enhanced bind()/PORT_RESERVED access controller, we can forbid
root to pass traffic, but permit inetd, running as root, to accept
incoming connections. e.g

	# killall inetd
	# addgroup inetd
	# chgrp inetd /usr/sbin/inetd
	# chmod g+s /usr/sbin/inetd
	# inetd
	# ipfw add pass tcp from any to any established gid inetd
	# ipfw add padd tcp from any to any 21,79 setup in gid inetd

Is a good start at eliminating covert channels.

Speaking of inetd, does someone care to commit my virtual hosting
patches?

Cheers,
Julian.