Re: [binc] A couple of security concerns.

[Ivan M.]

Before I reply, I think I'd better briefly explain my own security 
philosophy first.

There are really two different ways to approach computer security.  The 
first says that computers should be really easy to use, and the user 
should be able to do anything unless the sysadmin has determined that it 
is a security risk and has therefore blocked it.  This is the approach 
used in Windows and, clearly, it doesn't work.  In fact, this is the 
main reason why Windows is inherently insecure, in spite of many years 
trying to fix it.  I don't even think it *can* be fixed.

The opposite approach is to lock down everything except that which has 
been determined to be safe after careful investigation by the sysadmin.  
Functionality is passed out parsimoniously, and only to specific 
individuals according to their specific needs.  This is the approach 
generally used on large mainframes and professionally managed UNIX 
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 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.

Andreas Aardal Hanssen wrote:
bincimapd has no concept of users or groups; it's not bincimapd's job to
act as an authority there.  bincimap-up does, but it's perfectly fine to
run bincimapd as root. If you want to prevent this, you can either modify
bincimapd, or introduce a script which wraps bincimapd, first checking if
you are running as root. Binc IMAP is very flexible in this sense.
Example:
#!/bin/bash
test `whoami` == 'root' && exit 111
exec $@
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.

Unfortunately, Dr. Root, like Dr. Jekyll, suffers from severe 
schizophrenia.  Most of the time, he is that friendly, helpful, genius 
who keeps the whole show going.  We trust him, not just because he is 
*like* us, but because he *is* us.

But, sometimes, he turns into the evil twin, Mr. Toor, who has just 
"toorn" through our defenses and become the spitting image of his 
innocent brother, Dr. Root.  And sometimes he turns into their half-wit 
sibling, Oort, who "ought" to know better, but in his ignorance keeps 
opening doors to places where he doesn't belong.

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).

It's not a server in that sense, and the way checkpassword works is that
checkpassword chooses the current working directory, and Binc IMAP uses
this. It's the design of checkpassword. And for configuration files, Binc
IMAP will not refuse admins from using relative paths in bincimap.conf.
 

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.

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.

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, 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).

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.
   

Thanks!
 

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!

--
------------------------------------------------------------------------
[EMAIL PROTECTED]
It is better to trust in the Lord than to trust in man. (Ps. 118:8)
------------------------------------------------------------------------