Date: Fri, 16 Mar 2001 22:09:11 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: Jack Rusher <jar@integratus.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-arch@freebsd.org, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' Message-ID: <200103170309.WAA92739@cs.rpi.edu> In-Reply-To: Message from Jack Rusher <jar@integratus.com> of "Fri, 16 Mar 2001 11:59:34 PST." <3AB270A6.77ADBBBD@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think something like what you have proposed is pretty reasonable. I >would say that more would be required to make this useful. My >discussion will be constrained to PKI as part of kernel. I think the power in this is that it is 'useless'. That is to say that this is just a method for placing and identifying authentication information in the kernel, and leaving everything else up to the authors of the authentication modules. We do need some basic set of APIs (to do reference counting, etc... see email to Terry Lambert), but we need to keep this as minimal as possible. > > After you have a means to store a public/private key pair in the >kernel you will need to provide a syscall like interface to the service >that uses the credential that is stored in the kernel. Something like: > > o login gets key pair from new /etc/passwd (or whatever), uses >password typed by user to unencrypt 3DES'd private key, verifies that >the key really has been unlocked by using the public/private key pair to >encrypt and decrypt a message, stores private key in pcred for use by >later syscalls. > > o Later programs use a syscall interface to to sign, unencrypt, etc, >by calling a ksign_message(...) style routine. > > You would need to avoid any syscall interface that allows the user to >fetch the unlocked private key from kernel space. Otherwise, any >program the user runs can snatch a password equivalent and store it for >later. > > What this functionally means is that you would need to make a generic >crypto services API at the kernel level and use loadable modules to >support the algorithms you are interested in. This means moving a lot >of openssl into kernel space. This is daunting for most people. > > I want to see this happen to support an NIS replacement I am working >on right now. I would want to see the kernel crypto API published and >lobbied to the other BSDs & Linux so that we would be able to write >portable applications that expect kernel crypto support. > > How many other people are interested in something like this? Does >everyone else think we should just use PAM and get over it? :-) Everything that you have listed here would be implemented in an auth module. I certainly would be interested in a NIS replacement. I wouldn't worry about it conflicting with PAM, they answer fundamentally different questions. PAM is a method for authenticating a user/service. NIS and its cousins is a method of distributing database type information. The way computers work there is some overlap between PAM and NIS (I need to know user 'X's password, I look it up in some form of database). -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103170309.WAA92739>