Re: From: '' <> whitelisted?

[Steve Thomas <li...@sthomas.net>]

> How is it that this (weird, sort-of-null) From: address is whitelisted?
> It's surely not listed in my local.cf or user_prefs.  Any ideas?

>From RFC 2821:

--------------------------------
   If an SMTP server has accepted the task of relaying the mail and
   later finds that the destination is incorrect or that the mail cannot
   be delivered for some other reason, then it MUST construct an
   "undeliverable mail" notification message and send it to the
   originator of the undeliverable mail (as indicated by the reverse-
   path).  Formats specified for non-delivery reports by other standards
   (see, for example, [24, 25]) SHOULD be used if possible.

   This notification message must be from the SMTP server at the relay
   host or the host that first determines that delivery cannot be
   accomplished.  Of course, SMTP servers MUST NOT send notification
   messages about problems transporting notification messages.  One way
   to prevent loops in error reporting is to specify a null reverse-path
   in the MAIL command of a notification message.  When such a message
   is transmitted the reverse-path MUST be set to null (see section
   4.5.5 for additional discussion).  A MAIL command with a null
   reverse-path appears as follows:

      MAIL FROM:<>

--------------------------------

Whether or not the null sender should be in the default whitelist is
subjective, but I think most would agree that it's prudent.

Re: bayes_journal permissions

[Matt Kettler <mk...@evi-inc.com>]

Pollywog wrote:
> On 12/06/2005 12:27 am, Matt Kettler wrote:
> 
>>David Buttrick wrote:
>>
>>>Is there a control for the permissions on the bayes_journal file?
>>>
>>>I'm using a shared bayes db, and users do not have permissiosn on the
>>>file because it is created chmod 600.
>>>
>>>Is there something i can do in the config files?
>>
>>What's your bayes_file_mode setting set to?
>>
>>If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due
>>to use in dir creation)
> 
> 
> 
> Wouldn't it be better to set bayes_file_mode to 0770 and add the users to the 
> same group as the file, say "users" group?
> 
> 
> 8)

That works too, although you also have to add "nobody" to that group (any mail
set to scan as root falls back to nobody).


At that point the difference between 0770 and 0777 is not exactly very large.
Sure named, http, cron and other service users can't write it, but that's about it.

For someone exploiting as a service user, It *might* be possible to privilege
escalate by maliciously corrupting the bayes DB. However, when using spamd bayes
is never accessed as root so the potential gain here is small, you'd only be
able to escalate to a regular local user, not to root. From there they might
have better tools available to hop into root via another privilege escalation,
but it's a long shot that they couldn't just do it directly from the service user.

While I agree it's a good idea from a "belt and suspenders" approach, there are
better measures one should take first. (ie: make sure all network daemon
processes are chroot as well as setuid)

Re: bayes_journal permissions

[Pollywog <li...@shadypond.com>]

On 12/06/2005 12:27 am, Matt Kettler wrote:
> David Buttrick wrote:
> > Is there a control for the permissions on the bayes_journal file?
> >
> > I'm using a shared bayes db, and users do not have permissiosn on the
> > file because it is created chmod 600.
> >
> > Is there something i can do in the config files?
>
> What's your bayes_file_mode setting set to?
>
> If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due
> to use in dir creation)


Wouldn't it be better to set bayes_file_mode to 0770 and add the users to the 
same group as the file, say "users" group?


8)

Re: bayes_journal permissions

[David Buttrick <db...@geekforce.com>]

Thanks!

On Dec 5, 2005, at 6:27 PM, Matt Kettler wrote:

> David Buttrick wrote:
>> Is there a control for the permissions on the bayes_journal file?
>>
>> I'm using a shared bayes db, and users do not have permissiosn on the
>> file because it is created chmod 600.
>>
>> Is there something i can do in the config files?
>
> What's your bayes_file_mode setting set to?
>
> If you have a shared bayes db, it should be 0777 (note: 0777 not  
> 0666 due to use
> in dir creation)
>

Re: bayes_journal permissions

[Matt Kettler <mk...@evi-inc.com>]

David Buttrick wrote:
> Is there a control for the permissions on the bayes_journal file?
> 
> I'm using a shared bayes db, and users do not have permissiosn on the 
> file because it is created chmod 600.
> 
> Is there something i can do in the config files?

What's your bayes_file_mode setting set to?

If you have a shared bayes db, it should be 0777 (note: 0777 not 0666 due to use
in dir creation)

bayes_journal permissions

[David Buttrick <db...@geekforce.com>]

Is there a control for the permissions on the bayes_journal file?

I'm using a shared bayes db, and users do not have permissiosn on the  
file because it is created chmod 600.

Is there something i can do in the config files?

Thanks.

David

Re: From: '' <> whitelisted?

[Steve Thomas <li...@sthomas.net>]

> 1) null sender isn't in the default whitelist
>
> 2) the rule matched isn't due to the default whitelist, as that would show
> up as
> USER_IN_DEF_WHITELIST, instead of USER_IN_WHITELIST.

I guess I need to brush up on my SA rules vocabulary.. :)


> 3) The message in question has the null path as it's From: header address,
> this
> is COMPLETELY different from the return path mentioned in RFC 2821.

Yes, it is, and I realized my mistake about the same time as I released
the mouse button from clicking "Send". Someone else had asked about the
return-path, and I was waiting on a response to that before correcting
myself, if necessary.

Re: From: '' <> whitelisted?

[Matt Kettler <mk...@evi-inc.com>]

Steve Thomas wrote:
>>How is it that this (weird, sort-of-null) From: address is whitelisted?
>>It's surely not listed in my local.cf or user_prefs.  Any ideas?
> 
> 
> Whether or not the null sender should be in the default whitelist is
> subjective, but I think most would agree that it's prudent.

Well, three points:

1) null sender isn't in the default whitelist

2) the rule matched isn't due to the default whitelist, as that would show up as
USER_IN_DEF_WHITELIST, instead of USER_IN_WHITELIST.

3) The message in question has the null path as it's From: header address, this
is COMPLETELY different from the return path mentioned in RFC 2821.



Really I suspect this has to do with SA looking at *MANY* headers other than
just From: when checking to see if the message should be whitelisted. I suspect
this message has a whitelisted domain or address in the Resent-From:,
Return-Path:, Resent-Sender:, Envelope-Sender:, or in one of the Received: headers.