From owner-freebsd-current  Sun Dec 15 16:05:19 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA19376
          for current-outgoing; Sun, 15 Dec 1996 16:05:19 -0800 (PST)
Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA19347
          for <freebsd-current@freebsd.org>; Sun, 15 Dec 1996 16:05:04 -0800 (PST)
Received: (from news@localhost) by haywire.DIALix.COM (8.8.3/8.8.2) id IAA05456 for freebsd-current@freebsd.org; Mon, 16 Dec 1996 08:04:35 +0800 (WST)
X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f
Received: from GATEWAY by haywire.DIALix.COM with netnews
	for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com)
To: freebsd-current@freebsd.org
Date: 16 Dec 1996 00:04:33 GMT
From: peter@spinner.DIALix.COM (Peter Wemm)
Message-ID: <5923mi$1pj$1@haywire.DIALix.COM>
Organization: DIALix Services, Perth, Australia.
References: <199612152022.PAA05216@skynet.ctr.columbia.edu>
Subject: Re: Plan for integrating Secure RPC -- comments wanted
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In article <199612152022.PAA05216@skynet.ctr.columbia.edu>,
	wpaul@skynet.ctr.columbia.edu (Bill Paul) writes:
[..]
> The sucky part about all this is that I would have to implement
> my own name service switch and make all kinds of modifications to
> the system to support it. Also, if I understand things correctly,
> static executables can't call dlopen() and friends in 2.2 and 3.0
> since those functions are in crt0.o, but not in scrt0.o.

I kinda offered to fix that before but never got around to it.  Perhaps
I should..  On SVR4.0+ systems, there are several cc/ld options.  -dn and
-dy control whether crt0.o or scrt0.o is used.  ie: you can link with all
static libs, but still have the dynamic linker present for manual dlopen().
I can implement this fairly easily, as well as putting stubs in scrt0.o.

> In TI-RPC, Sun did away with keyenvoy and made keyserv use the
> loopback transport. They also took advantage of certain features
> in SysV networking that allow keyserv to learn the UID of the process
> on the other side of the transport endpoint. (I don't quite understand
> how it works, but it uses t_getinfo().) This credential information
> is set by the kernel, hence it's not possible for the client to
> falsify it (unless it has root privileges, but if this is the case
> then system security has already been compromised and you have bigger
> problems).
> 
> Unfortunately, BSD doesn't have any equivalent mechanism for learning
> the UID of a process on the other side of an AF_UNIX socket, and
> we don't have STREAMS/TLI networking. This presents a serious problem
> since it is vital for keyserv to have such a mechanism in order for
> its security model to work.

Three more options spring to mind..
1: extend sendmsg()/recvmsg() a little so that they can pass a "credentials"
structure over a local domain socket that is "certified" by the kernel.
check kern/uipc_usrreq.c:unp_externalize() etc.
2: Implement a aocket ioctl() to get the credentials of the remote partner
(or creator) on an AF_LOCAL connection.
3: use fd passing over the AF_LOCAL socket and/or ticket files of some sort.
eg: create a pipe() as user, pass fd keyserv via sendmsg().  keyserv does an
fstat() on the fd and confirms that it's a pipe.  It should be able to
read the stat.st_uid to get the creator.

-Peter