Date: Mon, 16 Dec 1996 09:39:59 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted Message-ID: <199612161440.JAA07129@skynet.ctr.columbia.edu> In-Reply-To: <11680.850740486@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 01:48:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Poul-Henning Kamp had to walk into mine and say: > In message <199612152022.PAA05216@skynet.ctr.columbia.edu>, Bill Paul writes: > > Hi Bill, > > Thanks for sharing your thoughts on this. I finally found time to > read it, and here are my comments: > > For the DES pollution: > > Put DES in the kernel. > > This could be as an LKM, which would be the easiest, or as > a proper kernel-source file, which would be slightly harder > to manage distributions-wise. > > Result: > * You avoid your planned hack. > * We could do away with the two versions if libcrypt we have > now, and collapse them into one. > * Which makes the dual versions of /bin/ed, /sbin/init ... > unneeded. > * Our secure dist would consist of only the LKM file. > > Drawback: > * Minor optional kernel bloat. Mmm... lemme think. We have to consider all the possible ways this can fail. Urk: just thought of one. If the crypt(3) function is an LKM, then it has to be loaded by the rc scripts, right? Well supposing you take away the 'secure' keyword from /etc/ttys for the console, then try to boot single user. /sbin/init will want to ask you for the root password before it'll give you a shell. Then you're stuck: it hasn't loaded the LKM yet, so it can't verify your password. If crypt(3) and _des_crypt() were static parts of the kernel, then you wouldn't have this problem I suppose. But then you'd have to recompile the kernel to add DES support. Hm. Then again, maybe not... I think what might work is if we have both. The kernel source contains static syscall code that implements the MD5 crypt(3) and a fake _des_crypt() that does RC4 (which I gather is exportable, if you stick to 40 bits for the key). Then we have an LKM which contains the true DES versions of these calls, and when you load it, it overrides the vectors to the dummy syscalls with vectors to its own calls. That way you always have some version of the functions present. Oh wait, no no... that still won't work. Taking the example I gave before, if I set the root password using the DES crypt(3), then I boot in single user mode, /sbin/init will again ask me to enter the root password before it gives me a shell, and now it'll try to verify my password using the MD5 crypt(), which will never match the output of the DES crypt(), and I'm stuck again. Crap. Do we really want to make people recompile the kernel to get DES support? > For the issue of a secure local transport: > > Wouldn't it be pretty easy to fortify our IP implementation a bit ? > > 1. reject anything with source/dest 127.0.0.0/8 on anything > but the lo0 interface. (Add a interface flag for this and > only set that flag in if_lo.c) > > 2. In the case of a destination of 0.0.0.0, Instead of the > first interface we happen to find, use the lo0 interface > and the 127.0.0.1 address. > > This way you could use tcp/udp and be safe I belive. Well, there's another neat thing about the "unix" transport, which is that since it's not AF_INET, you avoid all the usual IP protocol processing. Also, the server can set the permissions on the socket special file that it creates so that only certain clients can access the service. If someone really wants to fix the IP layer as you suggest then that's fine, but it's not strictly necessary. > For the issue of authenticated local transport: > > Instead of an LKM, put the code in the kernel. It shouldn't be too > hard to make it a getsockopt() instead of a LKM. I'll check into this. I don't really consider myself an advanced enough kernel hacker for this, but maybe I'll get lucky. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612161440.JAA07129>