On Thu, Jan 13, 2005 at 10:25:15PM -0700, Ivan M. wrote: > Before I reply, I think I'd better briefly explain my own security > philosophy first.
Interesting! :) > There are really two different ways to approach computer security. [..default ACCEPT vs. default DENY..] > I use this approach in all of the software I write and I think all > professional programmers should do the same. It is our > professional duty toward society and we ignore it at our peril. I'd say that the UNIX way is specifically to allow our good friend the doctor and his many alter egos to flourish at will. If someone wants to build a UNIX system where root runs all processes, fine, let them. But after a while they probably wont have very many customers left. On the other hand, no-one can really claim that UNIX was intended to be a professional system, rather a fun system for professionals. :) Then came systrace. http://www.citi.umich.edu/u/provos/systrace/ [..] > All software should be written with these two siblings in mind and, > yes, it *is* bincimapd's job to act as an authority here. I politely disagree. No application should be written to _limit_ usage, that's a task for the kernel. If the restriction lies in user space, there will always be a number of ways to circumvent it. > In fact, im some jurisdictions it could be considered legally > *required*. You could be sued if, unlikely though it may seem, > somebody does, somehow, become root and then gains unauthorized > access to important email information. > You have been warned, you haven't fixed it, and you *are* liable. > (Don't blame me, I write software, not laws). Obviously those laws are really stupid; if an administrator makes a mistake, the administrator should be liable. Not the maker of the software that was erroneously configured. But I guess that this kind of thing is what promotes disclaimer clauses in licenses, as the ones present in the GPL, for example. I doubt anyone can win a suit against a GPL license claiming some kind of warranty when the license clearly states that there is none. I also write software however. Meanwhile I think I'll just stay out of those jurisdictions, to make absolutely sure I don't lose my mind. :) > It is, too, a server. It runs from the super server, xinetd, in > response to a connection from the "outside" on a well known port > specifically assigned to servers. No, not really. bincimapd runs from checkpassword, which runs from bincimap-up, which runs from tcpserver, which runs from xinetd or supervise. So tcpserver is the server, even if it only runs for a short period of time before invoking the next program in the chain. > It does not run as a command line program, accessible only to a > trusted set of local users. Actually, bincimapd will run just fine from the command line, it needs a couple of environment variables but with them set it will start speaking IMAP with you so you can access the mail depot in the current working directory. Just like qmail-pop3d. > You *cannot* reasonably trust the > program that invokes you, even if you think it was written by > someone you trust. Because the service is security critical, > and initiated from outside, you have a responsibility to take > *more* care than you might for a simple command line utility. Take care when processing protocol input, yes. But the outside does not provide execution state, that is done by the administrator through checkpassword, and should be trusted. Otherwise you'll end up with an X popup; "Do you really wish to start Binc? <Yes> <No>" whenever someone wants to access their email. Sounds a lot like that other OS, huh? :) > are ways to improve on this. In our distro, programs in /sbin are > executable *only* by root. If other users need the functionality, > and after careful consideration, we make it available to them from > /bin. If the kernel does not restrict the users, nothing can. If other users need functionality that is allowed by the kernel but disallowed by e.g. a permission on a binary file, they can try to get another binary onto the system in a large number of ways. > I *have* protected the password stub, by putting it into /sbin (in > our distro). I suggest that you protect the password stub primarily by carefully validating input data rather than focus on limiting local execution possibilities, after all it will always be reachable from the network. :) > But no amount of wrapping can keep bincimapd from being run > directly by Toor or Oort. Only bincimpad itself can protect us > from them. (Note that you *have* to allow the password stub to run > as root, otherwise it can't change to the effective user). If Toor or Oort show up, Root will soon gain much wisdom. > I only hope that the server system I'm working on will make an > additional useful contribution, especially for Windows users, like > Oort. Just out of curiosity, will it be open sourced? Do you have an URL for the project? > I'm not nit picking, or criticizing you. Just trying to give you > the benefit of my 35+ years experience in this bitness! I think we all appreciate another viewpoint! I certainly do. But at the same time I humbly believe that you have gotten used to way too much politics interfering with your code.. :( //Peter
