[rsbac] Dazuko installation
ao at rsbac.org
Sun Jul 17 10:24:25 CEST 2005
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
> There is zero documentation so here's what I've done myself:
> - Enabled onaccess scanning in clamav.conf
Should look like:
> - created /dev/dazuko device (that works with udev too I guess ? I
> 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
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
> - got not denies in rsbac log (starting clamd in softmode gives the
> 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
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...
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
More information about the rsbac