On Wed, 12 Mar 2003, Andreas Aardal Hanssen wrote: > Hi, Charlie. > > On Tue, 11 Mar 2003, Charlie Brady wrote: > > > >I'm still mystified as to why all this extra (relatively) complex code > >exists. > > But I hope you agree that we are not changing interoperativity with > checkpassword, as I beleive you first feared.
No, that wasn't me. > Note that the only thing that makes this design secure is if the preauth > module is much more simple and restricted than the post-auth code, so that > the overall chance of failure in the preauth module is lower than in the > postauth module. The preauth code can certainly be expected to be much simpler and more restricted than the post-auth code. But that's not the only thing that can assist in making that design more secure. The pre-auth program can give up various privileges after it no longer needs them. For instance, after spawning the authenticator, and before parsing any user input, it can switch to an unprivileged user. Using capabilities, it can give up the capability to read and write files, or create network sockets. > However, I agree that this is a good design and I will implement it. Excellent. I think the first thing we need is for bincimapd to implement a pre-authenticated mode. > Binc does not have priviledge seperation yet, and I have said before that > it will be introduced. Good. I don't think that it will be difficult. > >Andreas, are you wedded to the current authentication scheme? Or might you > >be convinced to have the authenticator spawn bincimapd rather than the > >other way around. > > I'm not wedded to the design. I am looking into priviledge seperation. > However, Binc IMAP's authenticator is not checkpassword. If we want the > authenticator to only support checkpassword and not the stdin-stdout > method Binc uses today, then I too see no reason for the daemon not to be > spawned by the authenticator. _However_, checkpassword support is simple a > bundled stub. The native authenticator behaves differently. It does. Does it need to? Is there any advantage in the native authenticator? > By "invoked similarly" I mean that it is spawned through a tcp wrapper. It > will support privilege seperation. But I am not convinced that the > authenticator should spawn the daemon. These last two statements appear to be contradictory. I think that the authenticator must spawn the daemon to provide the privilege separation. Perhaps I'm wrong. But since that model is simple, and we have good models and component parts, why shouldn't we do it that way? Or as Caskey put it: what is so broken about checkpassword that it is critical enough to warrant creating a *new standard* to fix. -- Charlie
