srivasta@debian.org--etch/refpolicy--debian--0.0--versionfix-7
srivasta@debian.org--etch/refpolicy--debian--0.0--versionfix-9

 * courier.fc specifies labelling for most of courier's files, buth
   virtually all of these have the "--" constraint which makes them apply
   only to (regular) files.  This means that /var/run/courier/authdaemon
   doesn't get labelled, and hence when the authdaemon socket is created
   therein, it has the type var_run_t.  The other courier components
   aren't allowed to read var_run_t (they have courier_var_run_t
   instead), so authentication breaks.  Removing the -- seems to fix it:
   (Merged upstream in 2aa70bc0 (2011-03-09), thanks to Sven Vermeulen)

 * courier.fc also has a specific label the authdaemon executables, whose path
   expression /usr/lib(64)?/courier/authlib/.* doesn't match the Debian
   packages; the correct pattern for Debian's paths would be
   /usr/lib(64)?/courier/courier-authlib/.* .  This leaves authdaemon running
   in initrc_t or something equally unhelpful.
   (Merged upstream in 2aa70bc0 (2011-03-09), thanks to Sven Vermeulen)

 * The POP & IMAP servers still can't connect to authdaemon, because they're in
   courier_pop_t while authdaemon is in courier_authdaemon_t (with the above
   fix).  The fc gives courier_pop_t read/write permissions on
   courier_authdaemon_t:tcp_socket, but authdaemon listens on a UNIX domain
   socket; I'm not entirely sure it _can_ listen for TCP.   This policy seems
   to fix it, although adding another line in upstream's courier.te allowing
   the same access from courier_pop_t to courier_authdaemon_t:unix_stream_socket

 * authdaemon doesn't work in itself, because although it can connect to its
   own UNIX domain socket, it can't accept connections or do anything else with
   them.  Um, yeah.
   (Merged upstream in 3db4e7fb (2011-03-09), thanks to Sven Vermeulen)

 * courier-imap-ssl (and probably the SSL POP daemon also, but I didn't try
   that one) use an SSL session cache in /var/lib/courier/; it's created by
   the first writer.  However, because the fc only labels files, the directory
   itself stays labelled as var_lib_t and the cache can't be created (and if it
   could, it would have the wrong type.)  Here's the offending line; removing
   the "--" and relabelling fixes this one

 * Once connected, the IMAP server can't setuid/setgid to the proper account,
   if so specified by the userdb, because it hasn't been granted either of
   those capabilities.  courier_pcp_t (that's a C) can, but courier_pop_t
   can't.

 * The IMAP server also can't read symlinks in user_home_t.  These are often
   placed inside a Maildir to expose another maildir/mbox as a subfolder.  This
   restores that ability, to no significant loss of security I can see on the
   face of it
   (This one was removed in 0.0.20090621-1)

 * Finally, courier-imap has sometime recently started using fam to watch for
   changes in the Maildir.  This involves going through portmap, connecting to
   arbitrary ports to talk to famd, etc.  Bleh.  It's optional, and if the
   attempt fails it will poll the directory instead, but it makes a fair
   amount of noise in the logs (the attempt is repeated on every write to
   the maildir). This is not fixed.

Index: policy/modules/services/courier.te
===================================================================
--- policy/modules/services/courier.te.orig
+++ policy/modules/services/courier.te
@@ -89,7 +89,8 @@
 # POP3/IMAP local policy
 #
 
-allow courier_pop_t courier_authdaemon_t:tcp_socket rw_stream_socket_perms;
+allow courier_pop_t self:capability { setgid setuid };
+allow courier_pop_t courier_authdaemon_t:{ unix_stream_socket tcp_socket } rw_stream_socket_perms;
 allow courier_pop_t courier_authdaemon_t:process sigchld;
 
 allow courier_pop_t courier_tcpd_t:{ unix_stream_socket tcp_socket } rw_stream_socket_perms;