Bug#734294: maildrop compiled with trusted user setting which seem to reduce security

2014-01-31 Thread Osamu Aoki 

On Mon, Jan 13, 2014 at 09:44:23AM +0100, Josip Rodin wrote:
 On Sun, Jan 05, 2014 at 05:23:22PM +, Graeme Vetterlein wrote:
  I am trying to use maildrop tacked onto the back of fetchmail(1) as in:
  
  ... options fetchall mda /usr/bin/maildrop -d testing
  
  This is reading what is in effect a multidrop mailbox, usinsg maildrop(1) 
  config
  to replace the lack of envelope information
  
  I run fetchmail as the user 'fetchmail' for reasons of security.
  The -d option will not work on debain build of maildrop (as it lacks u+s 
  bit)
  if I add u+s , -d is now allowed BUT fetchmail (user) gets the message:
  
  You are not a trusted user
  
  Doing strings(1) on /usr/bin/maildrop seems to suggest the compiled in 
  trusted users
  are 'mail root and daemon' .
  
  1: I don't see these names documented
  2: There is no option to maildrop to reveal which optiosn were used in 
  compile
  3: The Normal way to get this to work would be to run fetchmail as root 
  (trusted user + no need for u+s)
 but exposes me to the obvious risk ... I run fetmail(1) because I (like 
  many otheres) don't want to risk an incomming SMTP
 
 Well, the obvious question is, why exactly do you need delivery mode if
 you're already unprivileged? Why can't you run fetchmail itself as the
 this testing user?
 
 -- 
  2. That which causes joy or happiness.
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734294: maildrop compiled with trusted user setting which seem to reduce security

2014-01-13 Thread Josip Rodin 
On Sun, Jan 05, 2014 at 05:23:22PM +, Graeme Vetterlein wrote:
 I am trying to use maildrop tacked onto the back of fetchmail(1) as in:
 
 ... options fetchall mda /usr/bin/maildrop -d testing
 
 This is reading what is in effect a multidrop mailbox, usinsg maildrop(1) 
 config
 to replace the lack of envelope information
 
 I run fetchmail as the user 'fetchmail' for reasons of security.
 The -d option will not work on debain build of maildrop (as it lacks u+s bit)
 if I add u+s , -d is now allowed BUT fetchmail (user) gets the message:
 
   You are not a trusted user
 
 Doing strings(1) on /usr/bin/maildrop seems to suggest the compiled in 
 trusted users
 are 'mail root and daemon' .
 
 1: I don't see these names documented
 2: There is no option to maildrop to reveal which optiosn were used in compile
 3: The Normal way to get this to work would be to run fetchmail as root 
 (trusted user + no need for u+s)
but exposes me to the obvious risk ... I run fetmail(1) because I (like 
 many otheres) don't want to risk an incomming SMTP

Well, the obvious question is, why exactly do you need delivery mode if
you're already unprivileged? Why can't you run fetchmail itself as the
this testing user?

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734294: maildrop compiled with trusted user setting which seem to reduce security

2014-01-05 Thread Graeme Vetterlein 
Package: maildrop
Version: 2.5.5-2
Severity: wishlist

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

I am trying to use maildrop tacked onto the back of fetchmail(1) as in:

... options fetchall mda /usr/bin/maildrop -d testing

This is reading what is in effect a multidrop mailbox, usinsg maildrop(1) config
to replace the lack of envelope information


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I run fetchmail as the user 'fetchmail' for reasons of security.
The -d option will not work on debain build of maildrop (as it lacks u+s bit)
if I add u+s , -d is now allowed BUT fetchmail (user) gets the message:

You are not a trusted user

Doing strings(1) on /usr/bin/maildrop seems to suggest the compiled in 
trusted users
are 'mail root and daemon' .

1: I don't see these names documented
2: There is no option to maildrop to reveal which optiosn were used in compile
3: The Normal way to get this to work would be to run fetchmail as root 
(trusted user + no need for u+s)
   but exposes me to the obvious risk ... I run fetmail(1) because I (like many 
otheres) don't want to risk an incomming SMTP

   * What was the outcome of this action?
   * What outcome did you expect instead?

4: It would help if this were runtime configurable (e.g. /etc/maildrop.conf) so 
I could decide who was trusted.

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.0.4 (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages maildrop depends on:
ii  courier-authlib  0.63.0-6+b1
ii  libc62.13-38
ii  libgcc1  1:4.6.3-1
ii  libgdbm3 1.8.3-11
ii  libpcre3 1:8.30-5
ii  libstdc++6   4.6.3-1

Versions of packages maildrop recommends:
ii  exim4  4.80-7
ii  exim4-daemon-light [mail-transport-agent]  4.80-7

maildrop suggests no packages.

-- Configuration Files:
/etc/maildroprc changed:
logfile /var/log/maildrop/$LOGNAME.log
ECHO=/bin/echo
MAIL=/usr/bin/mail
REFORMAIL=/usr/bin/reformail
SPAMHEADER=X-WB-spam:
MAILDIR=$HOME/mail
SPAM=${MAILDIR}/spam
if (/^X-Spam-Flag:\s+Y/)
to $SPAM
if (/^Subject:.*-SPAM-/)
to $SPAM
if (/^X-pn-pstn: Spam\s+[12345]/)
to $SPAM
if (/^TO.*donotsend*/)
to $SPAM
if (/^TO.*graeme@vetterlein.com/)
to $SPAM


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org