AntiVir Server for UNIX 2.1.11

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

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

See http://www.avira.com/faq for an online list of frequently asked questions
and their answers.


System requirements
-------------------

In order to run AntiVir software on certain systems, it may be necessary to
install or activate additional components.

FreeBSD 6:
Running AntiVir software on FreeBSD 6.x requires installing the compat5x
distribution. This is because the AntiVir software was built for FreeBSD 5
systems.

64-bit UNIX (Linux, FreeBSD, OpenBSD, Solaris):
Running AntiVir software on 64-bit UNIX systems requires the ability to execute
32-bit binaries. Refer to the documentation of your particular UNIX system to
see how to enable this ability (if it is not already enabled). For the
on-access scanner (AvGuard) at least version 2.1 of Dazuko is required.


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

Scanning for viruses is not optional, but the software optionally can scan for
other unwanted kinds of software, too.  For each kind there are commandline
options of the form "--with-<type>" and "--without-<type>" as well as config
file directives "Detect<type>".  In the absense of those keywords the default
settings apply.

The current list of types and their default state is: "ADSPY" (on), "APPL"
(off), "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.  The logfiles contain messages of a similar
form.

Although the layout will not change, it's possible for the specific alert
names to differ between software versions or after VDF updates.  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.


The 2006/Q4 release (antivir 2.1.9-x) introduced the "--alert-urls=<yes|no>"
option for on demand scans to print "ALERT-URL:" lines to the screen and the
report file where more information on the concern is available.  The
"ExternalProgram" Guard feature will expand the "%SU" macro to the alert URL.


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

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
deprecated.  We *strongly* suggest to retire the /etc/antivir.conf file and to
switch to the appropriate config files for the scanner, product and update
related parameters.  Although the /etc/antivir.conf file is currently supported
for backwards compatibility, support will be removed in a future release.

Settings for AntiVir Server and AntiVir Workstation go to /etc/avguard.conf.
Settings for the AntiVir Samba Scanner go to /etc/avsamba.conf.  The updater
gets configured with /etc/avupdater.conf.  (Other products like AntiVir
MailGate, AntiVir WebGate, the AntiVir Virus Scan Adapter and AntiVir SAVAPI
based 3rd party applications have their configuration in /etc/avmailgate.conf,
/etc/avwebgate.conf, /etc/avsapvsa.conf and /etc/avsavapi.conf, respectively.)


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.

A new "--via-savapi" command line scanner switch was introduced, see the
"SAVAPI based on demand scans" section for a more thorough description.


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.


Memory consumption and issues with SunOS
----------------------------------------

Since memory (physical RAM plus swap space) on SunOS is used to hold the /tmp
directory hierarchy as well, and since forking off a new process on SunOS
actually allocates the complete "vsize" for the new process without waiting for
the copy on write feature to really use this memory, problems may arise on this
OS which won't be seen on other systems.

When configuring the number of daemons (the NumDaemons config file directive),
make sure that an appropriate amount of free memory is available.

The software defaults to /tmp for temporary data -- unless the system or the
software was configured otherwise, by setting the $TMPDIR environment variable
or by specifying the TemporaryDir config file directive -- on all systems, but
defaults to /var/tmp on SunOS which should slightly improve the situation.


SAVAPI based on demand scans
----------------------------

The 2007Q1 release introduced support for on demand scans against a SAVAPI
server which already was started in background.  This feature dramatically
reduces startup times for the on demand scan and is of special benefit for
situations where many short scan requests are started with their own on demand
scanner process each (like the integration of AntiVir into AMaViS).

SAVAPI (Secure AntiVirus Application Programming Interface) is an approach
where a daemon process sitting in the background provides AV scan services to
3rd party applications or other SAVAPI based products.  Updates are handled
transparently -- the AntiVir updater restarts currently running SAVAPI server
processes after updating the files on disk, SAVAPI clients will reconnect and
continue their sessions against an updated software version.

There are two basic modes to run a SAVAPI server.  The traditional approach
forks off one scanner process per client session, which allows for an arbitrary
number of client sessions but puts quite some system management load on the
machine.  A so called SAVAPI proxy mode sets up a pool of scanner processes of
configurable size, while these scanners are assigned to the SAVAPI clients as
they connect.  This limits the number of concurrent sessions to the scanner
pool's size (plus some entries in a queue waiting for a short amount of time
for a scanner to become available), but greatly increases throughput and
reduces system load when SAVAPI sessions usually are short (only a few files or
even one single file per session, or in other words one SAVAPI session per file
to be scanned).

The SAVAPI server process is started with the "antivir --ondemandsavapi" or
"antivir --ondemandsavapi-proxy" command.  An AntiVir Server license is
required to start the SAVAPI server.  The server establishes an AF_UNIX socket
which only clients running under the same account can connect to.

The on demand scan is started with the usual command line options and
parameters as they were used before, plus the newly introduced "--via-savapi"
option.  Instead of loading and initializing a local version of the scan engine
a connection to the SAVAPI server is established and scanning starts
immediately.  The SAVAPI server won't get started automatically but instead is
expected to run already.


Heuristic analysis and on access scans
--------------------------------------

Starting with the 2007Q1 release the on access scanner uses heuristics level 2
by default.  But to reduce the impact of false positives the configured action
(renaming, moving or deleting files) is not taken should the alert in a sample
consist of heuristic matches exclusively.  In any circumstance access to such a
file will be denied.


Integration with SMC management
-------------------------------

In order to configure updates via the Security Management Center (SMC), it is
necessary to add the updateplugin package to the SMC repository. Once added, a
new product "Avira Updater" will be available for installation on machines
administered by the SMC. The "Avira Updater" product allows updates to be
configured for all products installed on machines administered by the SMC.


Updating from a local mirror
----------------------------

By default, the Internet Updater fetches new versions of the software from the
official Avira download servers.  Optionally the Internet Updater can be
redirected to use a local mirror to check for and fetch updates, which is
important when the mirror-script or Internet Update Manager is used.

The Internet Updater can be configured for a local mirror with the
"HTTPUpdateServer" directive in the /etc/avupdater.conf file.  This directive
takes specifications in the following form:

  HTTPUpdateServer http://mirror-host[:port]/[path/]


Active status and alert monitoring
----------------------------------

The already available notification methods (issuing messages to the
system's logging daemon or to custom log files, sending out email
messages, running external processes with user specified commands) were
extended in the 2007Q3 release for easier integration into desktop
environments.

The "ActiveLockFile" config file directive takes an absolute path spec
to communicate the on access scanner's activity status to some instance
which does the visualization to the user (e.g. by changing icons in a
panel).  The "ExternalProgram" config file directive can be used to
popup notification windows on the user's desktop.

See the software in the contrib/applet directory for an example how to
make use of this extension.

The "ActiveLockFile" feature is not available on SunOS.

