Date: 16 Dec 1996 00:04:33 GMT From: peter@spinner.DIALix.COM (Peter Wemm) To: freebsd-current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted Message-ID: <5923mi$1pj$1@haywire.DIALix.COM> References: <199612152022.PAA05216@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5923mi$1pj$1>