$Id: README.AVP,v 1.5 2002/07/27 14:39:35 mjt Exp $

AVP, an AntiViral Toolkit Pro, is available from www.kaspersky-labs.com.
It is very good antivirus product.  But as usual, it has somewhat flaky
implementation in the unix part.  I personally do not recommend to use
it just for this reason.

By default, AVP installed to run as root -- this is a *very bad idea*.
Who can tell us that it is safe to run a piece of unknown software,
written by people who has little unix expirience (not to say about unix
security!), as root?!  I personally recommend to run it as dedicated user
(as described in avcheck manpage), *and* putting it into the chroot jail --
just to be shure that it will not affect other parts of system in any case.
Setting it up in this way is tricky, but for me, it is better to spend
some (probably hard) time setting it up instead of determining why your
system is open to everyone and cracked...

Fortunately for us, kavdaemon program, at least for Linux, linked statically,
so it is relatively easy to put it into chroot jail.  On other OSes, some
additional steps will be required to properly set up a chroot jail for it.

First, create one unix group, avgroup, and two users, avdaemon and avpclient,
having group avgroup as primary group for both:

  groupadd avgroup
  useradd -g avgroup -d /non/existant -s /bin/false -c "AVP Daemon" avdaemon
  useradd -g avgroup -d /non/existant -s /bin/false -c "AVP Client" avclient

(note: this example works on Linux, on other platform command lines
might be different).

Then, create directories where all the AVP stuff will be placed (assuming
your current umask is 022), and setup device entries needed for kavdaemon:

  mkdir /var/spool/avp
  cd /var/spool/avp
  mkdir bases ctl tst tmp dev proc
  chown avdaemon:avgroup ctl
  chown avclient:avgroup tst
  chown avdaemon tmp
  chmod 750 tst ctl
  chmod 700 tmp
  cp -a /dev/null /dev/console dev/

Example of directory listing on a linux machine:

drwxr-xr-x    9 root     root         1024 May 10 12:03 ./
-rw-r--r--    1 root     root          117 May 10 11:51 AvpUnix.ini
-rw-r--r--    1 root     root          737 May 10 11:34 AvpUnix.key
drwxr-xr-x    2 root     root         1024 May 10 11:44 bases/
drwxr-x---    2 avpd     avgroup      1024 May 22 19:55 ctl/
-rw-r--r--    1 root     root         1880 May 10 12:03 defUnix.prf
-rwxr-xr-x    1 root     root       750008 Apr 23 12:33 kavdaemon*
drwxr-xr-x    2 root     root         1024 May 10 11:42 proc/
drwx------    2 avdaemon root         1024 May 10 11:42 tmp/
drwxr-x---    2 avclient avgroup      1024 May 10 12:25 tst/
drwxr-xr-x    2 root     root         1024 May 10 11:42 dev/
crw-------    1 root     root       5,   1 Apr 30 13:01 dev/console
crw-rw-rw-    1 root     root       1,   3 Aug 14  2000 dev/null
drwxr-xr-x    2 root     root         1024 May 10 11:52 etc/
-rw-r--r--    1 root     root          815 Feb  2  2000 etc/localtime

You may also add a /dev/log entry, but it requires additional
syslog daemon configuration.

See also below some addidional and/or different steps required
on other OSes or when kavdaemon linked dynamically.

The "idea" is using the principle of least privilege: only give those
permissions that are absolutely necessary.

Some descriptions for those directories inside /var/spool/avp:

  /var/spool/avp itself: a root for all avp "activity"/files.
    This directory will be modified only during the installation,
    kavdaemon and avcheck will not write to it or modify files here.

  bases/  here we will place AVP's antivirus bases.  It shouldn't be
    writable for avp daemon and client, but should be readable for
    daemon.  Having all bases in separate directory simplifies
    maintenance.

  ctl/ here kavdaemon will create it's control socket (AvpCtl)
    and pid file (AvpPid).  The directory should be writable for daemon,
    accessible for client (as a member of avgroup), and unaccessible
    for any other user (so that noone else will be able to talk with
    the daemon)

  tmp/  I'm not shure if it is really needed, but kavdamon may use
    it for it's own purposes.  This directory should be private for
    avdaemon user.

  tst/  this is a main testing directory, where mail files will be
    placed temporary for checking by a daemon.  Should be writable
    for avclient user (the client that will actually process mail),
    accessible for avdaemon (so that daemon will be able to read a
    file from there for testing), and unaccessible for anyone else,
    to enshure that no one will look to our mail messages.

  proc/  this directory exists only to make kavdaemon quiet -- or
    else it will complain "unable to open /proc" on each run.

Next, fill in bases/ directory with current antivirus bases
(root:root, mode 644 will sufficie), and place daemon itself and
it's configuration into top-level /var/spool/avp directory.

Changes in kavdaemon configuration.  Remember that kavdaemon will be
run chrooted, so it will see /var/spool/avp as / -- all paths should
be modified accordingly.

There are two configuration files used by kavdaemon: defUnix.prf and
AvpUnix.ini.  Place those files into top-level chroot directory, and
copy the kavdaemon executable here too.  AvpUnix.ini contains base
settings like paths etc, and should be modified as follows:

 KeysPath=/      # place AvpUnix.key file into /var/spool/avp/
 BasePath=/bases # where bases can be found

Next, defUnix.prf file.  Some values should be changed, or else
things will not work.  Below is a list of recommended changes.
Note that format of defUnix.prf file changes over time, and various
parameters may be in different parts of a file.  Please locate
every parameter in your defUnix.prf before changing it.

List=/tst
# which objects will be allowed to scan;
# note that sometimes kavdaemon wan't look into here,
# and this list should be repeated in it's commandline too

MailBases=No
# MailBases are things like MS Exchange, MS Outlook and so on mail
# storages, in internal format.  There is no need to enable scanning
# of such "files" (we will scan only plain mail messages), and according
# to avp's docs, it will run slower if MailBases will be set to yes

Warnings=No
# This is to stop avp giving warnings on false positives.  When avp
# encounters a file that *looks* like virus, it will give a warning.
# Avcheck will treat such a file as infected.  Setting this parameter
# to No prevents this.  Note that such a "false positive" may in fact
# be NOT false.

InfectedAction=0
# This one is important.  By default, kavdaemon will ask what to
# do with infected mails.  We need only to know if mail is infected
# or not.  Avcheck will complain "uexpected avp return code NN (0xXX)"
# (with numbers in place of NN and XX) if you will not change this
# parameter to 0 (to mean: do *nothing* with infected messages, only
# report that them are infected!)

ShowOk=No
ShowPack=No
Report=No
# We don't need tons of messages in syslog!
UseSysLog=No
# In case /var/spool/avp/dev/log doesn't exists.  Note that
# this file can't be just created using mknod or something,
# at least on Linux (but on Solaris, creating conslog may
# help).  On Linux, addition `-a /var/spool/avp/dev/log'
# option should be specified in syslogd startup script
# in order to allow chrooted kavdaemon to do syslogging.

All other values may be copied from default configuration files.

Next, you will need to place avcheck, it's `infected' helper and
uchroot somewhere.  I recommend to copy them into the same directory,
/var/spool/avp, for simplicity.

Now, start the kavdaemon.  The following big commandline is needed
to properly setup environment.  Do not worry about it's length --
it should be placed into startup script.

  /usr/bin/env - HOME=/ \
  /usr/bin/nice \
  /var/spool/avp/uchroot -u avdaemon /var/spool/avp \
  /kavdaemon -dl -f=/ctl /tst

Some resource limits can be specified here as well.

Look into rc.avpd script provided with avcheck distribution --
it is a complete startup script that may be used on many unixes
to start kavdaemon this way.

Some words about kavdaemon options (you can execute `kavdaemon -?'
to show descriptions):
  -dl - disable logging.  If not given, kavdaemon will create
    another separate process for logging (a great job, yes? ;)
  -f=/ctl - where to place AvpCtl and AvpPid files
  /tst - directory where it is ok to check files for viruses
    (Location.List option in defUnix.prf)

Now, after kavdaemon is ready, you can test the installation:

 /var/spool/avp/uchroot -u avclient / \
 /var/spool/avp/avcheck -n -f root -d /var/spool/avp/./tst \
  -s avp:/var/spool/avp/ctl/AvpCtl root < eicar.msg

(Note that uchroot above used just like `su' command.)
Your infected script should run.  In case of any trouble,
avcheck will print an error message to stderr and exit with
EX_TEMPFAIL code, so you will be able to correct the problem.

In order to ensure that antivirus detection actually works,
you can temporary substitute infected script with this one:

  #! /bin/sh
  MAIL=$1 MSG="$2" FROM="$3"; shift 3
  echo "$MAIL (from $FROM, to $*) is infected:"
  echo "$MSG"
  rm -f $MAIL
  exit 0

Running the above line with this script should produce the
something like the following:

  /var/spool/avp/./tst/123.msg (from root, to root) is infected:
  infected by EICAR-Test-File

After you know that your avp setup works, you can configure
your mailsystem.  Read the corresponding readme file for this.

Notes about additional steps setting chroot jail.

The above mentopned sequence of commands to create chroot jail works on
Linux.  On other OSes, slightly different commands should be used,
especially when creating device entries.

On Solaris, device entries should be created as follows (thank to
Piotr Klaban for this):

  mknod conslog c 21 0
  mknod console c 0 0
  mknod null c 13 2
  mknod syscon c 0 0
  mknod sysmsg c 60 0
  chmod 666 null
  chmod 620 conslog console syscon sysmsg
  chgrp avgroup conslog console syscon sysmsg
  chgrp sys null

(The syscon and sysmsg special devices are used for kavdaemon syslog
message (one message) that is send even if there is 'UseSysLog = No'
setting in the defUnix.prf file.)

If kavdaemon executable linked dynamically (check with ldd command),
you need to create lib directory inside /var/spool/avp, and copy some
system libraries to it.  ldd will show what libraries are needed,
for example (on my solaris box):
  ldd kavdaemon
    libc.so.1 =>	/usr/lib/libc.so.1
    libdl.so.1 =>	/usr/lib/libdl.so.1
    ...
Copy all specified files (/usr/lib/libc.so.1 and so on) into
/var/spool/avp/lib directory, and do not forget the dynamic linker
itself (on Solaris, it is /lib/ld.so.1, on Linux - /lib/ld-linux.so.2
(for glibc2), on BSD - ?).

