AntiVir Server for UNIX 2.1.8

Release Notes
=============

This document lists changes which haven't made it yet into the PDF manual.


New support for AntiVir Server on 64bit versions of Linux and FreeBSD
---------------------------------------------------------------------

AntiVir Server (antivir version 2.1.3-41 and above) works on 64bit versions of
Linux and FreeBSD, too.  Please note that such a setup requires Dazuko version
2.1 or above.


New support for AntiVir Server on SunOS for i386
------------------------------------------------

The 2006Q3 release ships with a Dazuko module version 2.2.0-sunos9 which
supports SunOS on i386 processors.


New support for incremental VDF updates
---------------------------------------

The so called "incremental VDF updates" feature reduces network traffic (and
indirectly download times) when updating the VDF database.  After a period of
beta testing (where this feature had to be enabled by the user with an
especially named ".incvdf" file) it has become an official feature of the 6.33
release and is active by default.


Non virus but unwanted software categories:
-------------------------------------------

Other unwanted kinds of software than viruses are known to the program, too.
Each kind has a commandline option of the form "--with-<type>" to enable its
detection.  There is another "--without-<type>" option to explicitely turn off
detection.  The "--with-alltypes" and "--without-alltypes" command line options
are shortcuts to enable or disable the detection of all kinds of non virus but
unwanted software (scanning for viruses is not optional).  The "--alltypes"
option is supported for backwards compatibility but is not recommended for use,
it may be removed in future versions of the software.

The config file has a "Detect<Type>" keyword to enable detection of this kind
of software.  The appropriate "DontDetect<Type>", "DetectAllTypes" and
"DontDetectAllTypes" keywords exist, too.  Upper or lower case in the keyword
does not matter.  In the absense of the keyword (when the line is missing or
when it is commented out) the default setting applies.

The current list of types and their default state is: "ADSPY" (on), "BDC" (on),
"DIAL" (on), "GAME" (off), "JOKE" (off), "PCK" (off), "PHISH" (on) and "SPR"
(off).  For compatibility with existing setups the "Dialer" and "PMS" types
are supported, too.


How alerts are logged, displayed and communicated
-------------------------------------------------

There are several situations where alerts are communicated in different ways.
This is of concern to the command line scanner, log files of scanning daemons
and the SAVAPI protocol.


The command line scanner outputs a line with the "ALERT:" tag, the alert's
name is enclosed in brackets.  With the 6.31 release (beginning with antivir
version 2.1.3-41) the alerts' names are a little more verbose.  The layout
actually did not change but the text inside the brackets looks a little
different.

This is an example of the output from the 6.30 release:

/path/to/file/filename
 Date: 13.10.2003  Time: 10:35:46  Size: 87040
 ALERT: [DIAL/000302 dialer] /path/to/file/filename <<< Contains signature of a cost-incurring dialer DIAL/000302 (Dialer)

This is an example of the output from the 6.31 release:

/path/to/file/filename
 Date: 13.10.2003  Time: 10:35:46  Size: 87040
 ALERT: [Dialer/000302 dialer] /path/to/file/filename <<< Contains signature of the dial-up program Dialer/000302


The logfiles have changed in a similar way (not with regards to the layout,
but in terms of the text which is printed on alerts).


With the 6.32 release the alert types will be rearranged so that the text
values in the alert type fields may change.  This should not cause any
problems since the information accompanying an alert were never meant to be
processed and interpreted by programs but were designed to be logged or
displayed to a user.  Again, the layout does not change, it's just that
different text values are communicated.


Please note that alerts are logged and communicated (and the "ExternalProgram"
feature gets triggered) even if the alert is repairable and access is allowed
after eliminating the concern.


New configuration items
-----------------------

A new configuration item "UpdateAction <component> <action>" has been
introduced for the updater.  The <component> part may be any of "mailgate",
"milter" or "webgate".  The <action> may be any of "none" (the default),
"check" or "fetch".  These settings cause the updater to handle the scanner
backend as usual so your AV scan service will always be up to date, and in
addition the updater will check for available updates or will even fetch an
archive with the new software to your local disk for your convenience.  The
newly introduced "UpdateStoreDir" config item allows you to specify where the
software archives should be stored, by default the directory
"/usr/lib/AntiVir/updcomp/" is used.  Available updates for the "mailgate",
"milter" or "webgate" components will not be applied automatically to your
local installation.


A new configuration item "SuppressNotificationBelow <source> <level>" was
introduced to control which email notifications should be sent out and which
are to be ignored because of too low a severity.  Valid keywords for the source
are "Scanner" and "Updater", valid keywords for the level are "Notice",
"Information", "Warning", "Error" and "Alert" (in ascending order).

By default all messages are sent out to the address specified with the
"EmailTo" keyword.  The default settings are these:

  SuppressNotificationBelow Scanner Notice
  SuppressNotificationBelow Updater Notice

If only alerts as well as error messages issued by the scanner should be sent
out, but not warnings (like "not scanned completely" messages for archive
files), the configuration needs to be set this way:

  SuppressNotificationBelow Scanner Error

If notices, information as well as errors from the scanner are not of concern
but only alerts should be sent by email, the configuration should read

  SuppressNotificationBelow Scanner Alert

In the above scanner related examples the updater would still send out messages
with level "Notice" and above unless told otherwise.  If the updater should not
send out warning messages or "updated" notifications, but still is to send
error information (about network problems or update errors), then the
configuration item should look like this:

  SuppressNotificationBelow Updater Error

If the updater should send out potential product information or migration tips
(README files from within update packages) as well as errors, but not low level
notices, the configuration might be set to this:

  SuppressNotificationBelow Updater Information


Starting from the 6.33 release AntiVir Server has more properties available
upon alerts.  The "ExternalProgram" config option now expands the newly
introduced macros "%St" (alert type), "%SA" (action taken) and "%Su" (user
accessing the file).

Stronger checks on the configuration items for AntiVir Server are applied, the
on access scanning daemon won't start without specifications for the access
mask, at least one directory to supervise or the number of scanners to use.
The "NumDaemons" setting only accepts values between (including) 3 and 20 plus
the value 0 to disable the service, values of 1 or 2 have never been useful and
will be refused now.


The 6.34 release introduced a so called smart extensions scanning mode.  Now
there are three different approaches to scan files:  only scan those files
which end in certain filename extensions (the "extlist" method), scan files
based on their file type as well as their file name (the "smart" method), and
scan all files regardless of their type or name (the "all" method).  Of course
the most intense scanning method takes the longest time to complete.

The "ScanMode" config file option takes any of the "smart" or "all" values.
The default value for AntiVir Server is "all".

The on demand scanner has a "--scan-mode=<mode>" command line switch, where
mode can be any of "extlist", "smart" or "all", "smart" being the default.
The "--allfiles" command line switch is supported for backwards compatibility,
but it's recommended to use "--scan-mode=all".


The 2006Q3 release introduced another archive scanning related limit: the
maximum number of files in one recursion level.  This limit can be set with the
"ArchiveMaxCount" config file directive or with the "--archive-max-count="
command line option.  By default there is no limit for the number of files in
an archive recursion level.


Configuration files
-------------------

New configuration files were introduced.  The /etc/antivir.conf file has been
depricated.

Beginning with the 6.32 release the file /etc/avupdater.conf is used for the
updater. The on-access scanner's configuration is stored in /etc/avguard.conf
(as before).

With the 6.33 release a new configuration file /etc/avsamba.conf was introduced
to hold the configuration specific to the AntiVir Samba Scanner.  Configuration
items stored in the /etc/avsamba.conf file are used in addition to what the
samba-vscan plugin passes to the scanner daemon (these settings are stored in
the samba.conf file of your Samba service).

Traditionally, configuration was stored in the /etc/antivir.conf,
/etc/avguard.conf, and /etc/avupdater.conf files. However, it is strongly
recommended NOT to use the /etc/antivir.conf file and instead to put
configuration items in the /etc/avguard.conf and /etc/avupdater.conf files.
The /etc/antivir.conf file has been deprecated and should be removed from
your system.

Although the software will continue to use the /etc/antivir.conf file if it
exists, this is only supported for backwards compatibility. Future versions
of the software will no longer read this file.

The configavguard script is not available any longer to configure the
on access scanner.  Instead the GUI should be used to setup the guard
preferences.  Alternatively the /etc/avguard.conf file can be changed
manually, while this method needs a manual restart of the on access
scanner for the changes to take effect.


New commandline switches
------------------------

A new command line scanner switch was introduced to have concerning files moved
into a quarantine directory.  The "--moveto=" option needs to be given an
existing directory as an absolute path specification, of course the directory
needs to be writable for the account running the on demand scan.

For a description of the "--archive-max-count=" command line option see the
above "ArchiveMaxCount" notice in the "New configuration items" section.


Updater changes
---------------

Traditionally the updater only used to restart currently running daemon
processes after renewing files on disk when the updater was run with the root
account.  This was to make sure that all relevant processes could be restarted.

Starting with the 2006Q3 release the updater can be run with a non root account
to replace files on disk as before (assuming that the account is permitted to
replace the files on disk).  But in addition the updater will restart the
scanner processes running under the same account the updater was started with.

Please note that only when the updater is run as root all currently running
scanner processes can be found and will be restarted after updating the
software on disk.


Issues with Linux 2.6 kernels and the on access scan feature
------------------------------------------------------------

More thorough and up to date information is available at the www.dazuko.org
site.  Other OS or distribution specific issues are listed in the FAQ at
http://www.dazuko.org/faq.shtml.  The http://www.dazuko.org/howto-install.shtml
document explains in more detail how to install the kernel module.


Since the AntiVir Guard daemons run on top of the Dazuko kernel module, it's
essential that this module is available and fully functional on a system where
on access scans will be used.  Unfortunately there are some issues with the
latest Linux kernels that need to be solved by the administrator because no
programmatic solution is possible.

The preferred method to interface with the Linux kernel to capture file events
is the LSM API.  This is the default method chosen by Dazuko's configure script.
But there are a few situations where Dazuko is unable to use the LSM API because
other software prevents it from accessing this interface:
- when Novell's AppArmor is used and is required (cannot be deactivated)
- when SELinux is used and is required (cannot be deactivated)
- when LSM is deactivated or Capabilities are statically builtin while the
  kernel cannot be recompiled

In these situations it's necessary to switch to the so called syscall hooking
method to interface with a Linux 2.6 kernel.  The associated --enable-syscalls
option was introduced with Dazuko version 2.3.0 and this feature was improved
with version 2.3.1, so at least the latter version should be used.  It's
essential to specify a System.map file as well with the --mapfile= option which
exactly fits the kernel which the module gets built for.

Unfortunately there are System.map files which declare kernel data pages as read
only while they actually are not.  But taking action at runtime based on this
information leads to a kernel BUG() when the information is incorrect.  Not
taking action based on this information when it's correct leads to Oopses and
crashes.  While this situation cannot be detected by software without actually
running into the problem -- there just is no way to determine at build time
whether the information is correct or not and the kernel API lacks the
possibility to check at runtime whether the affected pages actually are write
protected or not.

It's important that the administrator does know whether the kernel data pages on
the system actually are read only or whether they are not and were wrongly
declared so.  With this information the Dazuko configure script can be invoked
with the appropriate options.  Should this information not be available, a test
system should be used to try which approach works for such a configuration (this
is not suggested to be done on a production system).

Most distributions do not have read only kernel data pages.  Which is why the
Dazuko configure script assumes that the System.map information is not correct
and issues a warning message to this effect.  Should loading a module which was
built this way result in a kernel BUG(), the module unfortunately cannot be
unloaded and the machine needs to be rebooted instead.  The module then needs to
be built with the additional --sct-readonly flag passed to the configure script.

