You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by snowcrash+spamassassin <sc...@gmail.com> on 2007/02/15 03:48:05 UTC

what does the 'new' --allowupdates option to sa-update do?

i note in 'Changes',

 r503835 | felicity | 2007-02-05 19:30:00 +0000 (Mon, 05 Feb 2007) | 1 line
 bug 5240: disable plugins by default via sa-update unless new
--allowplugins option is specified


though i read the sa-update manpage, & read the commit here,

  http://www.gossamer-threads.com/lists/spamassassin/commits/92025

and, found nothing on the wiki, i'm unclear.

can someone explain why this is important?  what it does do for me?

as this is a new/recent change, does the addition of this option
TOGGLE any previously default functionality?

what do i need to do/change in order to keep my functionality 'as before'?

fwiw, my current sa-update cron job, that's been working fine until now, is,

  sudo -u spamassassin /usr/local/spamassassin/bin/sa-update \
  --channelfile /var/spamassassin/sa-update-channels.conf \
  --gpghomedir /var/security/gpg-homedir \
  > /dev/null

do i need to change it to not 'lose' any capability?

thanks.

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by snowcrash+spamassassin <sc...@gmail.com>.
> "sa-update -D" will tell you anything you want to know, such

there continues to be a belief -- not surprisingly by the 'experts' --
that debug output, rather than user-friendly output, is the answer to
all things.

1st -- and, yes it's my opinion, which i understand doesn't hold much
H2O -- is that there is a big difference between the two feedback
mechanisms.

2nd, in this "silly" case of 'allowplugins' -- as pointed out TO me
here, a 'mistake' in its application can end up with hostile root
executables in place. me? i think that's a bad thing, worthy of note &
clarity ...

but, no argument, "sa-update -D" provides the output.

> You specifically asked the folks in here for recommendation. This of
> course will be subjective...

yes. agreed. noone's arguing ... or criticising.  rather, i'm
acknowledging, and suggesting.

> Anyway, an attempt on being not subjective:  Defaults are there for a
> reason. Don't change a default, unless you fully understand the impact.

clear.

in this case, the *default* changed.  i didn't change the default. it
used to be ON, now it's OFF -- by default.

trying to fully understand the impact is exactly what i'm trying to do.

despite the seeming belief that, since others find it "clear" i should
too, iiuc, the purpose of the list _is_ to ask. bottom line, someone
ELSE changed the default, made mention of it in the changelog, didn't
explain it in a way that i understood -- which is my issue, not theirs
-- and so i asked.

now it's been answered.

thoroughly.

i've also added my $0.02 worth of request/suggestion. folks don't
agree -- at least enough to do anything about it.  that's fine.  i'll
have it documented internally for our own purposes.

everybody's happy.

thanks!  :-)

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by guenther <gu...@rudersport.de>.
> > I would say you should add allowplugins if and only if the following
> > three conditions hold:
> 
> this is a helpful -- but very subjective -- approach.

You specifically asked the folks in here for recommendation. This of
course will be subjective...

Anyway, an attempt on being not subjective:  Defaults are there for a
reason. Don't change a default, unless you fully understand the impact.

  guenther


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: what does the 'new' --allowupdates option to sa-update do?

Posted by snowcrash+spamassassin <sc...@gmail.com>.
hi,

> I would say you should add allowplugins if and only if the following
> three conditions hold:

this is a helpful -- but very subjective -- approach.

>  1) You trust the channel provider is not malicious

well, as in the case if the Project itself, and DOS, y'all _are_ 'nice
folks', 'n all.  but, beyond that? how to know ... ... ?

>  2) You trust that the channel is not going to be compromised by an
> outside agent (the GPG check is supposed to prevent that, but it's
> always possible to compromise a GPG key)

well, if compromise is possible, then it's always possible ... and,
per your arguments, that trust is never valid.  well, there _are_
shades of trust ...

>  3) The channel is known to distribute plugins, and you want to use
> these plugins by default without checking them first

is there an check -- with sa-update itself, or other -- to determine
what, if any, plugins are going to be distributed by/at a channel
subscription?

sure, one can subscribe, then dig around in the distro files, but,
imho, that's not the user-friendliest approach.

would be nice to have a check, e.g., "sa-update --channelfile 'blah'
--check-plugins", or something like ...

as, honestly, as i write here, without 1st checking, or perhaps
thinking on it a bit, i could NOT tell you whether or not the SARE
channels(s) i'm sa-update'ing do, or do not, install/include plugins.

i just don't know.

> Anyways, that's my opinion, though I'm not nearly as familiar with the
> update process as Theo is.

appreciated.

again, it's pretty clear that there _are_ options/choices to be
had/made, but the "i'm just a user, so what do i do now?" sort of
guidance is still -- as already pointed out, apprently just for me ;-)
-- a bit soft.

thanks.

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by Duncan Findlay <du...@debian.org>.
On Wed, Feb 14, 2007 at 08:09:57PM -0800, snowcrash+spamassassin wrote:
> since i certainly trust the project, and DOS' contributions, should i
> simply mod my cron jobs to,

> 	sa-update --allowplugins --channelfile .../DIST-channels.conf
> 	sa-update --allowplugins --channelfile .../SARE-channels.conf

> ?

> in the first case, its clear to trust ... but in the second (SARE)
> case, which channel/author am i actually trusting? DOS, SARE, others?

> what do folks here recommend?

I would say you should add allowplugins if and only if the following
three conditions hold:

 1) You trust the channel provider is not malicious
 2) You trust that the channel is not going to be compromised by an
outside agent (the GPG check is supposed to prevent that, but it's
always possible to compromise a GPG key)
 3) The channel is known to distribute plugins, and you want to use
these plugins by default without checking them first

Anyways, that's my opinion, though I'm not nearly as familiar with the
update process as Theo is.

-- 
Duncan Findlay

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by Theo Van Dinter <fe...@apache.org>.
On Thu, Feb 15, 2007 at 06:17:17AM -0800, snowcrash+spamassassin wrote:
> still, would be nice to be able to verify -- using cmd line option --
> what, if anyhting, the channel sa-update DID, in fact, 'send over'.
> namely, did/does it install a plugin, in addition to any rules, even
> IF disabled ...

"sa-update -D" will tell you anything you want to know, such
as "what files does this new update provide".  Otherwise, "cd
/var/lib/spamassassin/<version>/<update_channel>", and "ls" is pretty
simple IMO for already installed updates.  :)

-- 
Randomly Selected Tagline:
"Now let's say I like sheep...  And now let's say I take the sheep to a 
 Christmas party..."               - Bob Golub

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by snowcrash+spamassassin <sc...@gmail.com>.
> > > since i certainly trust the project, and DOS' contributions, should i
> > > simply mod my cron jobs to,
> > >
> > >     sa-update --allowplugins --channelfile .../DIST-channels.conf
> > >     sa-update --allowplugins --channelfile .../SARE-channels.conf
> >
> > my understanding of Theo's comments is no you shouldn't do that.  My
> > understanding of what he said was that none of the standard or SARE
> > channels update plugins this way.
> >
> >  From a security point of view you should not enable this by default, by
> > doing that you would be leaving a wide open security hole, which could
> > get compromised in the future.
> >
> > This switch is there for the rare occasion where you decide to allow a
> > channel to update a plugin automatically.  This is something you would
> > do only after reviewing that channel.
>
> Yep -- I can't see any standard channel needing to use it.  Typically
> if someone was to publish a channel that requires a certain custom
> plugin, they would indicate that in the channel's documentation...

all clear, now, thanks!

still, would be nice to be able to verify -- using cmd line option --
what, if anyhting, the channel sa-update DID, in fact, 'send over'.
namely, did/does it install a plugin, in addition to any rules, even
IF disabled ...

thanks.

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by Anthony Peacock <a....@chime.ucl.ac.uk>.
snowcrash+spamassassin wrote:
>> The man page is pretty straightforward IMO.
> 
> sigh.
> 
> ok.
> 
> as it's clear to one of the developers (!), it _must_ just be me, then. ;-)
> 
>> > do i need to change it to not 'lose' any capability?
>>
>> it depends on the channels you were using.  it doesn't change anything
>> for the official SA channel.  YMMV for third-party channels.  imo,
>> don't worry about it right now.
> <snip>
>> Hope this clarifies some more. :)
> 
> yes, it does clarify the "what?", nicely. thanks!
> 
> now, the "for which?"  is there a wiki page, or some commentay here on
> list (yet?), from others/all as to which/what to 'trust' -- or more
> importantly, *not* trust?
> 
> given that SA's scoring is all about building trust, and, at least at
> the beginning, accepting the "community's" recommendations for default
> scoring/trust, i'm curious, then, as to recommendations _here_.
> 
> e.g., _i_ currently run cron jobs that regularly exec,
> 
>     sa-update --channelfile .../DIST-channels.conf
>     sa-update --channelfile .../SARE-channels.conf
> 
> where,
> 
>     cat .../DIST-channels.conf
>         updates.spamassassin.org
> 
> and
> 
>     cat .../SARE-channels.conf
>         70_sare_obfu.cf.sare.sa-update.dostech.net
>         72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net
>         70_sare_evilnum0.cf.sare.sa-update.dostech.net
>         70_sare_evilnum1.cf.sare.sa-update.dostech.net
>         70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
>         70_sare_header.cf.sare.sa-update.dostech.net
>         70_sare_header_eng.cf.sare.sa-update.dostech.net
>         99_sare_fraud_post25x.cf.sare.sa-update.dostech.net
>         70_sare_spoof.cf.sare.sa-update.dostech.net
>         70_sare_random.cf.sare.sa-update.dostech.net
>         70_sc_top200.cf.sare.sa-update.dostech.net
>         70_sare_oem.cf.sare.sa-update.dostech.net
>         70_sare_unsub.cf.sare.sa-update.dostech.net
>         70_sare_uri.cf.sare.sa-update.dostech.net
>         70_sare_specific.cf.sare.sa-update.dostech.net
>         70_sare_oem.cf.sare.sa-update.dostech.net
>         70_sare_html.cf.sare.sa-update.dostech.net
>         70_sare_genlsubj.cf.sare.sa-update.dostech.net
>         70_sare_adult.cf.sare.sa-update.dostech.net
>         72_sare_bml_post25x.cf.sare.sa-update.dostech.net
>         70_sare_stocks.cf.sare.sa-update.dostech.net
>         99_FVGT_Tripwire.cf.sare.sa-update.dostech.net
>         bogus-virus-warnings.cf.sare.sa-update.dostech.net
> 
> since i certainly trust the project, and DOS' contributions, should i
> simply mod my cron jobs to,
> 
>     sa-update --allowplugins --channelfile .../DIST-channels.conf
>     sa-update --allowplugins --channelfile .../SARE-channels.conf

my understanding of Theo's comments is no you shouldn't do that.  My 
understanding of what he said was that none of the standard or SARE 
channels update plugins this way.

 From a security point of view you should not enable this by default, by 
doing that you would be leaving a wide open security hole, which could 
get compromised in the future.

This switch is there for the rare occasion where you decide to allow a 
channel to update a plugin automatically.  This is something you would 
do only after reviewing that channel.


-- 
Anthony Peacock
CHIME, Royal Free & University College Medical School
WWW:    http://www.chime.ucl.ac.uk/~rmhiajp/
"If you have an apple and I have  an apple and we  exchange apples
then you and I will still each have  one apple. But  if you have an
idea and I have an idea and we exchange these ideas, then each of us
will have two ideas." -- George Bernard Shaw

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by snowcrash+spamassassin <sc...@gmail.com>.
> Nope.  Neither include plugins, or other ways to load code, in their
> channels.  If they were to in the future I'm sure there'd be some
> attempt to make people aware of it.

got it. thanks!

> > in the first case, its clear to trust ... but in the second (SARE)
> > case, which channel/author am i actually trusting? DOS, SARE, others?
>
> My involvement in the contents of the channels goes no further than you
> trusting me to not have a setup that makes it easy (or even
> likely/probable) to compromise the channels and that I'm reproducing the
> same data available from the SARE website.  Beyond that I have no
> involvement.  I do not audit existing or new ruleset channels (new ones
> are created automatically).  Whatever SARE provides is what you get.  So
> whatever mechanisms they have in place to ensure you can trust them is
> what you're relying on (the same as if you were using RDJ or whatever to
> get the rules directly from them).

_that_ is clear. again, thanks.

your 'facts' do provide an example, given the discussion about
'channel trust', and imho, of the lack of documentation/clarity on
determining that trust -- for/by "just" end-users.  which is, in part,
why, i presume, so many folks suggested (per theo) that the option be
turned OFF by default ...

innocently misunderstanding/enabling 'allowplugins' seems to have the
_potential_ to have some seriously nasty consequences -- i.e.,
exec'ing a plugin w/ root privs! -- if improperly config'd.  a bit
more dire than, say, mis-scoring a rule!

although i still think some sort of proactive check/report of a
channel's activity -- namely, DID it install a plugin ? -- would be a
good idea, gievn lack of response/interest to the idea, i'll guess
that it's over-(or, silly-) engineering.

then, at lease, some additional explanation, clarity,
skulls-n-crossbones, etc added to the manpage/docs/wiki would be
helpful. DOS's comments, above, are a good start, i think ...

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
snowcrash+spamassassin wrote:

> since i certainly trust the project, and DOS' contributions, should i
> simply mod my cron jobs to,
> 
>     sa-update --allowplugins --channelfile .../DIST-channels.conf
>     sa-update --allowplugins --channelfile .../SARE-channels.conf

Nope.  Neither include plugins, or other ways to load code, in their 
channels.  If they were to in the future I'm sure there'd be some 
attempt to make people aware of it.


> in the first case, its clear to trust ... but in the second (SARE)
> case, which channel/author am i actually trusting? DOS, SARE, others?

My involvement in the contents of the channels goes no further than you 
trusting me to not have a setup that makes it easy (or even 
likely/probable) to compromise the channels and that I'm reproducing the 
same data available from the SARE website.  Beyond that I have no 
involvement.  I do not audit existing or new ruleset channels (new ones 
are created automatically).  Whatever SARE provides is what you get.  So 
whatever mechanisms they have in place to ensure you can trust them is 
what you're relying on (the same as if you were using RDJ or whatever to 
get the rules directly from them).


Daryl

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by snowcrash+spamassassin <sc...@gmail.com>.
> The man page is pretty straightforward IMO.

sigh.

ok.

as it's clear to one of the developers (!), it _must_ just be me, then. ;-)

> > do i need to change it to not 'lose' any capability?
>
> it depends on the channels you were using.  it doesn't change anything
> for the official SA channel.  YMMV for third-party channels.  imo,
> don't worry about it right now.
<snip>
> Hope this clarifies some more. :)

yes, it does clarify the "what?", nicely. thanks!

now, the "for which?"  is there a wiki page, or some commentay here on
list (yet?), from others/all as to which/what to 'trust' -- or more
importantly, *not* trust?

given that SA's scoring is all about building trust, and, at least at
the beginning, accepting the "community's" recommendations for default
scoring/trust, i'm curious, then, as to recommendations _here_.

e.g., _i_ currently run cron jobs that regularly exec,

	sa-update --channelfile .../DIST-channels.conf
	sa-update --channelfile .../SARE-channels.conf

where,

	cat .../DIST-channels.conf
		updates.spamassassin.org

and

	cat .../SARE-channels.conf
		70_sare_obfu.cf.sare.sa-update.dostech.net
		72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net
		70_sare_evilnum0.cf.sare.sa-update.dostech.net
		70_sare_evilnum1.cf.sare.sa-update.dostech.net
		70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
		70_sare_header.cf.sare.sa-update.dostech.net
		70_sare_header_eng.cf.sare.sa-update.dostech.net
		99_sare_fraud_post25x.cf.sare.sa-update.dostech.net
		70_sare_spoof.cf.sare.sa-update.dostech.net
		70_sare_random.cf.sare.sa-update.dostech.net
		70_sc_top200.cf.sare.sa-update.dostech.net
		70_sare_oem.cf.sare.sa-update.dostech.net
		70_sare_unsub.cf.sare.sa-update.dostech.net
		70_sare_uri.cf.sare.sa-update.dostech.net
		70_sare_specific.cf.sare.sa-update.dostech.net
		70_sare_oem.cf.sare.sa-update.dostech.net
		70_sare_html.cf.sare.sa-update.dostech.net
		70_sare_genlsubj.cf.sare.sa-update.dostech.net
		70_sare_adult.cf.sare.sa-update.dostech.net
		72_sare_bml_post25x.cf.sare.sa-update.dostech.net
		70_sare_stocks.cf.sare.sa-update.dostech.net
		99_FVGT_Tripwire.cf.sare.sa-update.dostech.net
		bogus-virus-warnings.cf.sare.sa-update.dostech.net

since i certainly trust the project, and DOS' contributions, should i
simply mod my cron jobs to,

	sa-update --allowplugins --channelfile .../DIST-channels.conf
	sa-update --allowplugins --channelfile .../SARE-channels.conf

?

in the first case, its clear to trust ... but in the second (SARE)
case, which channel/author am i actually trusting? DOS, SARE, others?

what do folks here recommend?

thanks.

Re: what does the 'new' --allowupdates option to sa-update do?

Posted by Theo Van Dinter <fe...@apache.org>.
On Wed, Feb 14, 2007 at 06:48:05PM -0800, snowcrash+spamassassin wrote:
> though i read the sa-update manpage, & read the commit here,
> and, found nothing on the wiki, i'm unclear.

The man page is pretty straightforward IMO.

> can someone explain why this is important?  what it does do for me?

It's security related, see below.

> as this is a new/recent change, does the addition of this option
> TOGGLE any previously default functionality?

Yes, certain config options are disabled from updates by default now.

> what do i need to do/change in order to keep my functionality 'as before'?
> do i need to change it to not 'lose' any capability?

it depends on the channels you were using.  it doesn't change anything
for the official SA channel.  YMMV for third-party channels.  imo,
don't worry about it right now.


The longer version is that before 3.1.8, any sa-update channel you used
had the option of including perl modules which the channel config could
then load for you.  This is a potential security issue if you think
about it -- a cron job you have could automatically download new code
and start running it, probably as root.

Now arguably, you need to have a level of trust to use an update channel,
but maybe you're not comfortable with that...  For example, when I was
at LISA '06's SpamAssassin BoF, everyone there basically said that they
would feel better if such things were disabled by default, and the SA
dev community generally agreed, so ...

What happens now is that any updates that are downloaded have certan
config options commented out during installation, such as loadplugin,
tryplugin, bayes_store_module, etc -- commands that will load modules.
I only know of one channel which shipped a *.pre file that loaded plugins
(standard ones, none included with the update), which IMO it shouldn't
have been doing anyway, so nothing is different for you.

Plugins provided by the channel will still be installed, so you could load
them manually if you wanted to.  Otherwise, if you trust the update channel,
you can use the new option and allow the channel to do what it wants.


Hope this clarifies some more. :)

-- 
Randomly Selected Tagline:
"They have this game where you put in a dollar and you get four quarters!  I
 win every time!"                - Family Guy