[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#557948: ssmtp severity 557948 normal



Aníbal Monsalve Salazar <anibal@debian.org> writes:
> On Mon, Jan 11, 2010 at 04:10:28PM -0800, Russ Allbery wrote:

>> At first glance, the analysis in the bug log from Rémi Denis-Courmont
>> appears to be correct to me.  Group mail is a privileged system group
>> which has read/write access to everyone's mail in one of the two mail
>> permission configurations that Debian explicitly supports (see Policy
>> 11.6).  It also allows a user in that group to delete anyone else's
>> mail spool due to the default permissions on /var/mail.  Overloading
>> that group to control who can send outgoing mail looks like a bad
>> conflation of two different privileges that will lead to users being
>> given excessive and unexpected privileges.

> I didn't want to create yet another group. Are you suggesting to create
> a new one just for ssmtp?

I assume the underlying difficulty is that ssmtp doesn't have a privilege
separation built into the software the way that most UNIX MTAs do, where
there's a daemon running with elevated privileges that the client talks
to?

Creating a separate group for ssmtp seems like a better solution than
using the mail group, yes.  Obviously, it would be ideal if there were
some way to not require users be added to a group to be able to use ssmtp,
since I think that's the expected MTA behavior and it sounds like that
requirement isn't an intentional feature.  But unless the SMTP
authentication can be done as a separate helper process that can run with
different privileges, it's hard to find a way to do that.

> I would like to fix it by ecrypting the password but it'll take me some
> time. If someone could provide ideas/hints/patches they will be very
> much appreciated.

I think that just moves the problem, though, doesn't it?  The ssmtp
process needs to have access to the encryption key to decrypt the password
if it uses any authentication mechanism that can't use pre-generated
digests, which means that now you have the problem that the ssmtp process
needs access to the key file to make sense of the password.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: