[Avcheck] Re: Porting avcheck to Solaris

[Michael Tokarev]

Piotr Klaban wrote:
> 
> Hi,
> 
> I have tested avcheck 0.3 + AVP on Solaris8,

Oh, I forgot a days when I worked on solaris.
There is a machine with 2.6 solaris in some dark
corner at our office, probably I'll go find it... ;)
For now, I not ever thought about that someone will
try to run things on solaris.

[]
> a) avcheck compile command need to have the following
>    libraries linked: -lsocket -lnsl
Yes, I remember this one.  Ok.

[]
> b) in the substlang.sh script the 'echo -n' command
>    is prohibitted for the Solaris' native /bin/sh shell.

Oh damn brOken solaris's shell.  It should NOT expand
escapes by default!  Note that except of this place,
there is another one in scripts exists, that is used
to output addresses as given by some *remote* user,
i.e. data received from a network.  There should be
something like /usr/5bin/echo or the like that
does the right thing.

>    I do not found any reasonable method for implementing it
>    in the right way (ie. portable, maybe you would use
>    autoconfigure in the future).

This is simple and ugly like a hell:
  if [ echo "x\c" | fgrep '\c' ] ; then
    echo_n=; echo_c='\c'
  else
    echo_n=-n; echo_c=
  fi
  ...
  echo $echo_n "stuff$echo_c"

> c) in the uchroot.c is the small bug:
> -    fprintf(stderr, ": %m");
> +    fprintf(stderr, ": %s", strerror(errno));

This is not a bug but a feature... ;)  of a gnu libc
(and probably BSD libc also).  Ok, will change this.

> d) I was unable to run the given 'infected' program, because of
>    for shell loop. I have changed:
> 
>   for i ; do echo " $i" ; done
> 
> to:
> 
>   for i in $@
>   do echo " $i" ; done

This is strange.  First note please that you should quote
$@ construct here -- just in case.  This is input from
remote system.  But anyway, solaris's shell also have similar
construct without "in ..." clause -- I'll check this.

[Got your second mail about INADDR_ANY -- also ok]

> During the installation/configuration phase:
> --------------------------------------------
> 
> e) in the README.Postfix file there is a spell mistake.
>    Instead of
>         localhost:1025 inet - n - - smtpd -o content_filter=
>    there should be
>         localhost:1025 inet n - n - - smtpd -o content_filter=

You're second who reported this.  I just copied the whole
line from original postfix's master.cf, modifying first
and last fields.  Well, I'll look to this one yet again
At a first glance, what a heck it should be public service
(i.e. why it's control socket should be in public dir?).
I looked into my master.cf yet another time, and now see
second variant and not what I provided.  Strange.
(I'm sorry, Fridtjof)

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (50)
# 1       2     3       4       5       6       7
# ==========================================================================


> f) suggestion:
>    There is a spell mistake in README.Postfix:
> 
>  avcheck unix - n n - 5 pipe
>         user=avc argv=/var/spool/av/avcheck
>                                  ^^
Yes it is, again, already pointed by Fridtjof Busse, and fixed already
in my "working" code.  I have no time (and there was no real reasons)
to make new release.

[]
> g) special devices can not be copied with cp -a (-a exists
>    only for GNU cp) since /dev/* are symbolic links to /devices
>    directory; however one can use (on Solaris8 only):
> 
>   cd /var/spool/avp/dev
>   /usr/sbin/mknod conslog c 21 0
>   /usr/sbin/mknod console c 0 0
>   /usr/sbin/mknod null c 13 2
>   /usr/sbin/mknod syscon c 0 0
>   /usr/sbin/mknod sysmsg c 60 0
>   chmod 666 null
>   chmod 620 conslog console syscon sysmsg
>   chgrp avp conslog console syscon sysmsg
>   chgrp sys null
> 
>   ls -la
> 
> crw--w----   1 root     avp       21,   0 Aug 28 15:02 conslog
> crw--w----   1 root     avp        0,   0 Aug 28 15:02 console
> crw-rw-rw-   1 root     sys       13,   2 Aug 28 15:02 null
> crw--w----   1 root     avp        0,   0 Aug 28 15:02 syscon
> crw--w----   1 root     avp       60,   0 Aug 28 15:03 sysmsg

Grr, what a mess -- one little antivirus needs so many files in
there... ;)  Ok.


> h) the kavdaemon is not static file, then there should be

?  I have only statically linked files here.  May be them sell
only linux versions statically linked (due to glibc versions
nightmare)?

Looking at all this I think it will be simpler to just run
avpdaemon in normal system root, non-chrooted...

> During the running phase:
> -------------------------
> 
> There is problem with uchroot: the /var/spool/avp filesystem MUST NOT
> be mounted as nosuid.

Aha -- wait...  It is better to move uchroot to some other place
then remount /var/spool/avp without nosuid.  I personally prefer
it to have nodev,noexec, but noexec isn't possible (kavdaemon
is executable after all!), and it needs some devices (again, I
just created all them as plain *files* here, instead of removing
nodev from /var's mountoptions).

[]
> BTW - in the main.cf file one need to add the 127.0.0.0/8
> network to the mynetworks variable (if it is not there by default).

Or give another different address for reinjection to avcheck
(i.e instead of localhost:1025, use your.real.host:1025).

You missed one another point with solaris: it has it's sendmail
in /usr/lib, not in /usr/sbin by default (or at least 2.1..2.6
version had), so you should also modify a script near SENDMAIL=.

> During the update phase:
> ------------------------
> 
> Sparc Solaris' version of AVP need to have two additional files

Wow, them now have sparc version!  Ok, but how about endianess/32/64bit
issues with their's protocol???  Avcheck should not run on sparc! ;)
BTW, is it (sparc) a 64 bit or 32 bit platform?  It might run on
32bit platform, but should not on 64bit...

> in the bases/ directory - packers.elb and elf.set. That is during
> the AvpUpdate phase that two lines should not be deleted -
> do it with two additional lines in AvpUpdate:
> 
>     285 $OldBase{$AvpKlb.".new"} = 0;
> +   286 $OldBase{'packers.elb'} = 0;
> +   287 $OldBase{'elf.set'} = 0;
>     288 foreach $f ( keys( %OldBase )) {
> 
> There should be perhaps also $OldBase{$AvpSet.".unix"} = 0;
> since the author advices to use avp.set.unix instead of avp.set
> in AVP configuration.

And this should be sent to kaspersky people -- it's problem in their
part.

Well....  I'll look to all this shortly (and together with other
suggestions, startup scripts and the like that was posted to
me and to list).  Thanks!

Regards,
 Michael.