[Gllug] ClamAV and Ubuntu
Nix
nix at esperi.org.uk
Mon May 16 13:35:10 UTC 2005
On Sun, 15 May 2005, Klunk whispered secretively:
> You already know me as Simon from CSFB, but now I have mail working
[mad bbdb]
(Ah, *that* Simon.)
[snip Ubuntu question I don't know the answer to]
> Question 2 is regarding Spamassassin. I am not actually running that
> yet. I went to turn it on and the daemon mode and it is disabled in
> the config. The config file suggests there are security holes in the
> daemon mode.
None are known, but there are security *concerns*, as there are with any
program which may run as root. If you want per-user Bayes or AWL, you
have effectively got two choices:
- store the Bayes and AWL files in the user home directories. This
means spamd has to be able to *write* to them, which means
(especially if your home directories are NFS-mounted) that it has
to be able to change user to the ID of the mail recipient. So spamd
has to run as root. (It drops these privileges almost at once, but
`almost at once' isn't the same thing as `at once'.)
- store the Bayes and AWL databases in an SQL database. You can run
spamd as a user of its own, then, without trouble.
In the former case, it's theoretically possible for an attacker to
remotely compromise spamd and get root. (No such holes have been
detected to date --- as I said, it drops its privileges rapidly.)
If you want per-user config files, you pretty much *have* to run as root
and let it change user to the user the mail's being delivered as.
If you run spamd at all, there are a few things to note:
- in SA 3.0x, work is distributed among the daemons (that is, among the
children which do the actual work) in a round-robin fashion. This
tends to keep them *all* swapped in, which can be a bit of a waste
of memory. (In 3.1+, it uses an Apache-style preforking algorithm,
which is much more memory-efficient.)
- if you don't run spamd as root, it's (pretty much) impossible for an
attacker to get root by attacking spamd, no matter what bugs may
exist in spamd or in Perl. However, a sufficiently clever attacker[1]
could craft a message that DoS-attacks spamd (perhaps causing it to
spend hours on a single message). Then he could send several of those
messages, gum up all the spamd children, and effectively stop your
spamd service. One such bug has been fixed (in 2.64).
It's also theoretically possible for a spamd attacker to corrupt
your SQL database and any other resources spamd has access to.
(There aren't many of those, and no such attacks are known.)
- You'll want to make sure you're running recent Net::DNS and Storable
modules. If the former is old, spamd's accuracy goes way down: if
the latter is old, you can see bugs ranging from spamd children
taking insane amounts of memory to children not dropping root
privileges when they should.
Nonetheless, I run spamd as root here, and have never had any problems.
(Running the spamassassin script is inefficient enough that there isn't
really an option, in any case.)
(Where's some wood, quickly! *touch* *touch* phew.)
[1] yes, I know Rule 1: `spammers are stupid.' Nonetheless, there is
a clever minority out there.
> Does anyone know what these are before I go turning this
> on?
Well, I don't know what they were referring to, but those are the ones I
was aware of. (Well, the ones I can talk about. There are a few
potential DoS attacks known fixed in 3.1, but they're effectively under
embargo right now until we can be sure that they're not too serious, or
until 3.1 is out so we don't blind-side people. There are to my
knowledge no holes in 3.02+ that might lead to anything more severe
than a DoS of spamd itself.)
--
`End users are just test loads for verifying that the system works, kind of
like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list