[Avcheck] Readme.avp

[Michael Tokarev]

Morten Christensen wrote:
> 
> Michael Tokarev wrote:
[]
> >I don't think this is a correct way.  Here is my a listing of
> >/var/spool/drweb from my machine:
> >
> >drwxr-xr-x    6 root     root         1024 Jul 24 14:29 .
> >drwxr-xr-x    2 root     root         1024 Jul 24 14:26 bases/
> >-rw-r--r--    1 root     root       570368 Jul 12 04:28 drweb32.dll
> >-rwxr-xr-x    1 root     root       931192 May 15 03:59 drwebd*
> >-rw-r--r--    1 root     root          501 Nov 20  2001 drwebd.ini
> >-r--r--r--    1 root     root         1165 Aug 14  2001 drwebd.key
> >drwxr-xr-x    2 root     root         1024 Oct  1  2001 etc/
> >drwxr-x---    2 drwebd   avscan       1024 Jul 24 14:29 run/
> >drwxr-xr-x    2 drwebc   avscan       1024 Jul 27 17:56 tst/
          ^^^ this is incorrect, should be drwxr-x---, 0750.

> Basically you give read- and/or exe-access to everybody,
> where I tried to restrict it to root and the av-group.
> I am no security-expert so I don't know what is best,
> or what is needed.

All the *real* restrictions placed on directories are really
necessary for:

 tst: noone except of client should be able to write there,
  and noone except daemon should be able to access any files
  there (email privacy).  Daemon should not be able to modify
  this directory and files within (to ensure that mail will
  not be modified even in case of bugs in daemon).

 run: directory holding control sockets, daemon creates it's
  socket here.  No other program should be able to perform
  a "DoS attack" against a daemon, and client should be
  able to access daemon's socket.

 tmp (not for drweb, probably not needed for avp) - in case
  daemon will want to write some temp file(s).  Such files
  may also contain private information (from email msg), and
  there should be no way to do somethin evil with a daemon
  trashing/changing temp files.

Other than that, no other user on a system should be able to
modify any files in those directories (well, except of some
process that will upload new virus signatures into bases/,
and rare cases when executables needs to be updated).

I hope you don't restrict permissions for /etc directory
allowing accessing files within for only a dedicated group.
This is possible and sometimes feasible, but such cases are
*so* rare and *so* special, and a person who does so should
understand why he does so and how to do so properly.

> I knew, that I probably hit too many files with my
> command, but I was unsecure on, where it was needed.
> 
> >(this is drweb not avp, and user/group names are somewhat different,
> >but the same rules applies anyway).
> >
> Does the avcheck and infected-executables need exe-access
> from the av-group?

Avcheck itself gets called by postfix with avclient:avgroup
user:group, so yes, postfix should be able to call it.  The
same is for infected-handler - avcheck is unable to change
it's uid/gid since it's not running as root.

I think it's okay to have world-accessible files (except of
those mentioned above) just like you have your /etc readable
by everyone.  Well, *some* files may be more protected as
stated in my previous email (.key for example).

The question is - what you want to achieve.   Those executables
are publicly available, so code analisys is possible without
reading them on your machine.  No executables here are setuid
or setgid.  The only possible harm may be an ability to execute
some binary program and crash it giving it some invalid arguments -
but heh, those programs aren't setuid or setgid anyway, so no
additional privileges will be obtained.

> Basically, does every file in /var/spool/avp need
> read or exe-rights from the av-group?

Well, almost.  Maybe except tmp directory that is private to daemon.

/mjt