Date: Mon, 16 Dec 1996 08:34:25 +0200 From: Mark Murray <mark@grondar.za> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted Message-ID: <199612160634.IAA24158@grackle.grondar.za>
next in thread | raw e-mail | index | archive | help
> Okay, I've decided on a final plan for integrating Secure RPC into > the main source tree. There were a couple of problems that had to be > dealt with which didn't have easy solutions, so I'm going to outline > them here to give people a chance to tell me they suck, call me a looney, > or present alternate solutions. YeeeeHaaaa! [snip] > Adding new authentication flavors > --------------------------------- [snip] > My other motivation for this is to allow the AUTH_GSSAPI authentication > code in the Kerberos V distribution to be added without having to > modify libc. The AUTH_GSSAPI implementation is provided as a completely > seperate version of the RPCSRC 4.0 library. If the code is imported > into the system as is, we will end up with two seperate RPC libraries > in the tree. This is pretty wasteful, and unnecessary if the RPC code > in libc allows new flavors to be added without modifying any code. Great! This will still allow that kluged AUTH struct in K5's RPC lib? Or does that have to be thrown out of the window? [snip] > The very suckiest is the solution that Sun uses in Solaris, namely > the name service switch. The name service switch uses shared objects > to contain the various kinds of lookup routines: files, DNS, NIS and > NIS+. You can even create your own. The top-level lookup routines Eugh... [snip] > The second solution is to put the DES support in the kernel. It's > possible to create a syscall LKM that implements the _des_crypt() > function and have libdesrpc call this system call instead of a > library function. A dummy LKM could be supplied with the core OS > that does no DES at all (or uses some other cipher that is exportable), > while a real DES LKM could be shipped with the secure dist. In this > case, no executables would have to be changed at all. Thus has distinct potential. A lightweight LKM that just xors the key to of the plaintext to generate a cipher (or something else that is weak and therefore both fast and exportable) would be OK. > The sucky part about this is that it bloats the kernel. It also has > 'kludge' written all over it in big red letters. I dunno - kernels can be made more secure than userland. > The third solution, which is the one I've settled on, is to create > a 'DES daemon,' i.e. a server program that does the encryption. [snip] Pretty good, but isn't it a little heavyweight? I could certainly live very happily with it, though. > The end result: you don't need to replace keyserv at all. To enable > DES support, you just copy libdes.so.3.x to /usr/lib, then restart > keyserv. Presto! You have real AUTH_DES support. No muss, no fuss, > no recompiling, no switching keyserv executables. :-) > The sucky part is that calling _des_crypt() as an RPC is slower > than calling it as a local function. Using an AF_UNIX socket helps > a little since the kernel doesn't have to do any protocol processing, > but it's still slower. (This also makes Secure RPC programs dependent > on keyserv, but in fact they're already dependent on keyserv anyway > because of how Secure RPC works.) Slowness helps prevent dictionary attacks - or am I talking crap in this instance? [snip] > - Adding new RPC authentication flavors: use svc_auth_reg() and supply > the code in a seperate library. Wonderful! > - Segregating the DES crypto code: move it all into keyserv(8) and > access it via remote procedure calls. (Also support runtime dynamic > loading of the libdes library and use RC4 as a replacement if DES > is unavailable.) My hero! > - Allowing keyserv to authenticate local clients: use a special system > call supplied as a loadable kernel module. Mumble - this sounds kinda klugy to me. I can live with it, though. > If nobody complains strenuously about any of this, I'm going to go > ahead and start importing things using this plan in a few weeks. (I > still need to finish rpc.ypupdated.) Comments, criticisms, screams > of terror, or large bags of cash are welcome and encouraged. I'm voting for you to go for it... M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612160634.IAA24158>