[rsbac] Dazuko installation

[Amon Ott]

On Samstag 16 Juli 2005 21:39, kang wrote:
> Anyone ever used the daz module ?

Yes, we use it in our main product for production. :)

> It works perfectly on the livecd but I am not able to make it 
working. 
> There is zero documentation so here's what I've done myself:
> 
> - Enabled onaccess scanning in clamav.conf

Should look like:

ClamukoScanOnAccess
ClamukoScanOnOpen
ClamukoScanOnClose
ClamukoScanOnExec
ClamukoIncludePath /

> - created /dev/dazuko device (that works with udev too I guess ? I 
did 
> it static to be sure)

The device must have the major shown in /proc/devices, which you can 
configure in RSBAC DAZ kernel config, and minor 0.

> - made sure daz module was on in /proc/rsbac-info/active
> - set /usr/bin/clamd as scanner

It must have been compiled with Dazuko (Clamuko)  support - e.g. 
Debian compiles without. There is also a bug in the configure script, 
so make sure not to give any clamuko parameter instead of explicitely 
enabling it.

And you must run clamd as root and give it sufficient RSBAC rights to 
read all files and dirs. Also, it needs the daz_scanner flag to be 
set, otherwise RSBAC denies Dazuko registration.

> - started clamd => got error in log: cannot connect to dazuko (and 
> indeed access to virii files are allowed)

This is usually the case, if /dev/dazuko points to the wrong device 
major.

> - got not denies in rsbac log (starting clamd in softmode gives the 
same 
> cannot connect error)

If you enabled caching (what is recommended), you will see DAZ_SCANNED 
numbers going up in /proc/rsbac-info/stats as soon as on-access is 
active. On our server systems, this quickly reaches a few thousand 
entries (caching overhead is still pretty low, much lower than 
without caching).

Two more notes: You should make sure that after updating virus 
patterns the cache is flushed, use daz_flush in the OnUpdateExecute 
directive in freshclam.conf.
Also, make sure that you use the latest svk/svn code - I have just 
corrected a bug in DAZ which in some cases did not reliably 
invalidate cache entries when a file got written to.

I guess we should put all this into the Wiki soon...

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : nicht verf?gbar
Dateityp    : application/pgp-signature
Dateigr??e  : 189 bytes
Beschreibung: nicht verf?gbar
URL         : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050717/405dc093/attachment.bin