On Wed, Jan 12, 2005 at 10:43:38AM -0700, Ivan M. wrote: > should never run as root, even accidentally. In the first version of > my password stub, I assumed that bincIMAPd still required root > privileges and would drop them as soon as possible (which is standard > practice). > So, I didn't set the user or group id's and, later, the daemon > created the mailbox with owner root.
As is expected from the interface between checkpassword and qmail-pop3d, which Binc has been designed to fit seamlessly into, to the joy of many MTA administrators. :) > Second, security conscious programs should not rely on the current > working directory (cwd), they should use absolute paths to their > configuration and data files (this, too, is standard practice). It > just never occurred to me that a server would assume a valid > working directory instead of setting the path itself from > /etc/password or, at the least, from the HOME variable. Which is why you should make sure to specify absolute paths in the run script, so that all of the programs invoked by it will actually be what you intend. I would say bincimapd _is_ security conscious, since it does not require root privileges (which would be neccessary to read user information with getpwnam()+friends or parse files "by hand") - instead that task is isolated in a very small and very auditable program; checkpassword. > On an insecure system it would be relatively easy to subvert An insecure system is, per definition, not secure. Binc is not supposed to fix that if it's an error; you are. ;) > Even so, I'm happy to have found bincIMAP. It neatly fits our > needs much better than the other well known IMAP servers. Thank > you, Andreas, for all your hard work. I agree, Binc rocks, and 1.4 will be awesome. :) (Yes, I know I'm getting ahead of myself a little, but I'm just stating the fact..) On Thu, Jan 13, 2005 at 09:40:05AM +0100, Andreas Aardal Hanssen wrote: > 2) When you're saying it's possible to break checkpassword, I > totally agree. So maybe the docs should mention that you should > never allow your checkpassword implementation to change to root, checkpassword may of course need those privileges to do it's job, but if not, there's absolutely no point. (e.g. MySQL database) > and that you can wrap bincimapd to prevent it being invoked as > root. I think this is pretty obvious from the run script design. There are at least a handful of really neat things that can be done with small wrappers in the tcpserver...bincimapd chain of commands that we've seen already, and who knows how many more? //Peter
