Hi again, Ivan. On Thu, 13 Jan 2005, Ivan M. wrote: > systems, and it works. This is the approach I take toward all computer > systems (although my philosophy toward human beings is the exact > opposite).
I understand your philosophy, and it's also a philosophy that I've had for many years. Basically, we make every effort possible to make a program as secure as possible, and never leave a single option available that opens the possibility for an exploit. It makes sense; I wouldn't allow a murderer into my home even if he was wearing handcuffs, so to speak. And the best way to keep a secret is to never tell anyone, or better yet, drink an amnesia potion, or best: don't have the secret in the first place. The best way to be safe from burglars stripping your house of valuables is to always keep it locked, and better yet, install a burglar alarm, and maybe get a watch dog, or even better: don't buy a house in the first place. Unix security is a very delicate topic, widely discussed, and like me and you, everyone has an opinion on what's best. The most rigid of security experts usually start off with questions like "why are you running this service at all?", and then, "why is it public?", "why must all of it be public?", "why is it running on the same C net as..", and so on. But in the end, everyone agrees that the most extreme security is when there's nothing to protect. Nobody wants 100% security. On the extreme opposite side, we have the public TCP bash server running as root on a public, unprotected IP (I actually _have_ experienced a sysadmin doing this). Extremely user friendly; no password, full access from all over the world (but the TCP port is secret! the IP has no DNS entry!). Funny and easy to do, but obviously absolutely ridiculous. The reason I bring this up is that silly admins do silly stuff. And as long as they continue to do silly stuff, no amount of preventive work will help. Two tools: bash, and tcpserver. Somewhere between these two cases, we find real life. And most applications have to find a compromise between user friendliness and security. And to reiterate: absolute security is power-off, unplug the network, rip out and wipe your hard drives, dip then into sulphuric acid and incinerate them. 100% security is course not interesting, but you can get very far with just 95% of absolute security. Consider why applications like "exec", "ps" and "cat" are allowed for root, and have little or no security measures. They are extremely simple, very useful, and every admin loves and uses them. I use "iptraf" all the time as root in promiscuous mode, and crond runs as root. Go check if "ping" is setuid root on your host. It almost certainly is. These tools are convenient, and a natural part of every security minded sysadmin's life. Imagine being a sysadmin in 2005 where "ps" could not be run as root, and where /proc was a read-only root-owned structure, and where it was impossible to choose what network interface to ping through. It's like welcoming a hero (read: sysadmin) to solve all your problems, but insisting that he wears a blindfold. My point is that I will not add code to Binc IMAP that covers the last 5% of absolute security, for the accumulated burden of 99% of the users of Binc IMAP. If a sysadmin wants to run Binc IMAP as root, that's a benefit the sysadmin has. If he wants to doubly prevent anyone else from doing the same, he'll install a wrapper or a patch, and run the server on a private network. If a distribution wants to lock down Binc IMAP, they can patch it or add a default wrapper by default. By stating this, I'm not compromising security; Binc IMAP is a very secure IMAP server. It uses privilege separation, and no parts need to run as root. It's the smallest IMAP server available and has the simplest logics you could find. You can run Binc IMAP on a private network, put a ulimit/softlimit on it, drop all privileges and isolate it. But it's still easy to use, easy to maintain, and easy to configure, unlike all other IMAP servers. The admin knows it's safe, because he knows what Binc IMAP is and what it's doing. Every extra option I add to Binc IMAP that executes authoritative security-minded code (like not relying on getcwd(), not using environment variables, never calling execve(), constantly checking the user ID and environment conditions, prechecking ranges of all arguments of all functions), limits its area of use, removes its straight-forward no-magic logics, and gives lots of sysadmins a headache. In the extreme case, we get software that is so secure that nobody knows how to install or use it, or even what it does at all. And on top of it all, we have to remember that every line of security enhancing code has the potential risk of introducing a bug that compromises security. Ironic, but very true. > 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. Professional software engineers have a duty to consider every reasonable aspect when writing code. It is not our duty to focus 100% on security at the expense of every other quality that is expected from modern software. We have to think about the total user experience, the ease of use, the maintainability, documentation, the security, the speed and efficiency. Speed itself often involves eliminating pointless boundary checks and dead code often associated with security. And to provide good documentation, you need simple, minimal logics. The best documentation is the one you don't have to write. It's practically impossible to prove code, as Donald Knuth said. And every line of code you introduce into your programs with the intention of achieving maximum security makes it harder to prove that your software is secure. And it makes it harder for your sysadmins to understand. > Andreas Aardal Hanssen wrote: >> Sysadmins who want to read their root mail can use bincimapd for that. >> If you are concerned about security, you forward your root mail to >> another user. > That is *precisely* why bincimapd should not allow itself to run as > root. Since he can read his mail as an ordinary user, he has absolutely > no business running IMAP at all. Well if he's not running IMAP, then he certainly doesn't need Binc IMAP at all! But if he _is_ running IMAP, he'll be happy to see that Binc IMAP does exactly what he expects. Yes, he should not reed his email as root. He most certainly knows. But there he is, and he's absolutely certain that the risk is neglectible. Binc IMAP should not give him a headache because it thinks it knows better. > All software should be written with these two siblings in mind and, yes, > it *is* bincimapd's job to act as an authority here. In fact, in 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). I'm not even going to attempt to make a statement against this form of actuallyism. Call me when you've found someone willing to sue me as author of Binc IMAP for them not securing their server. ;-) Even if it was Binc IMAP's fault, there is no case. Binc IMAP comes with an explicit no warranty, just like a certain big well-known company recently added to their own flagship software. > 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. It does not run as a command line > program, accessible only to a trusted set of local users. 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. The program bincimapd is no more a server than "ls" is the moment you run in in a TCP wrapper. If you don't agree to that, then we should simply move to the next point. http://www.exploitdatabase.com/view.php?name=11 http://www.exploitdatabase.com/view.php?name=83 Throughout the years, common simple tools have been the source of root exploits. They use mktemp, sprintf, make assumptions about the local directory, maybe they use execve wrongly or forget to check arguments and environment variables. So contrary to your last paragraph, even simple command line utilities need to keep lots of security measures. But there is a limit. At a certain point, a professional software engineer has to put down his foot and say "no, there is a limit to the level of lunacy I expect from my environment and users". Knives are sharp, coffee is hot, water is wet(!) and you can't breathe in it very well, but yet, "ls", "ps", "ping" and "hdparm" don't check if you're running as root. These tools expect a certain level of sanity from their system. >> 1) The difference between /bin/ and /sbin/ from a security standpoint >> is zip. > True, leaving /sbin out of the user's path doesn't help much, but there 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. So you don't allow regular users to create an ext3 filesystem on their diskette? You don't allow them by default to check the hardware clock? Maybe you disallow traceroute too. I'm telling you, nobody wants an absolute secure system if it takes away all their favorite tools. Then they will certainly move to an insecure platform where they can get some work done. Just see how many WinXP users always log in as administrator. And how many professional, intelligent, security-minded desktop Linux users add the setuid bit to sudo. Nobody wants absolute security. >> your checkpassword implementation to change to root, and that you >> can wrap bincimapd to prevent it being invoked as root. > I *have* protected the password stub, by putting it into /sbin (in our > distro). > 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). Toor and Oort can run bincimapd as Toor and Oort. If they want to run it as root, they need to break something that makes bincimapd run as root. They can't do that by going through the bash script wrapper. If they find a way to run bincimapd without going through the tcpserver -> bincimap-up -> checkpassword -> wrapper -> bincimapd path, then they are pretty silly if they choose bincimapd. I would personally have preferred "/bin/sh" or perhaps a root kit installer. And who says the password stub has to change users? Keep all your email under the "mail" user, and run bincimap-up, bincimapd and the password stub as "mail". No need to change users. For systems that need mail access to unix users, they can use the setuid trick. > You are truly more than welcome. I think the work of everyone in this > "thing of ours" is beyond anything anyone has ever done before for our > fellow man. I only hope that the server system I'm working on will make > an additional useful contribution, especially for Windows users, like > Oort. I'm not nit picking, or criticizing you. Just trying to give you > the benefit of my 35+ years experience in this bitness! And thank you for your contribution. Security is a very interesting topic indeed. I assure you that I'm not going to be unreasonable about this, but I am going to keep every single aspect in mind to make Binc IMAP a well recognized piece of professional software. And I will apply the logics where logics make sense. Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
