FAQ
General
What is Dazuko?
Dazuko aims to be a cross-platform device driver that allows applications to control file access on a system. By installing the driver, your system will be able to support file access control applications that are based on Dazuko. As this project becomes more popular and more applications choose Dazuko for their file access needs, it is hoped that this driver will become a common component of most systems.
How do I use Dazuko?
In order to use Dazuko you must first build and insert the kernel module. This then adds a new device to your system (/dev/dazuko). Once you have the Dazuko device, you can run applications that take advantage of the file access control features Dazuko provides.
If you are interested in building your own applications, check out the Dazuko interface specification. You may also want to look at the example program provided with Dazuko for a working reference.
A list of applications known to work with Dazuko can be found on the applications page.
What operating systems are supported by Dazuko?
The current release of Dazuko supports Linux 2.2-2.6, Linux/RSBAC, and FreeBSD 4.x-6.x kernels. However, it is slowly being expanded to support other operating systems such as MacOS X, Solaris, NetBSD, OpenBSD, and Windows. Although all these operating systems have very different control mechanisms, it should still be possible to integrate Dazuko.
What license is Dazuko under?
In order to allow Dazuko to be used on as many operating systems (both proprietary and free) as possible and in order for all software (both proprietary and free) to be able to incorporate the driver's interface, Dazuko uses a BSD license. However, the Dazuko device driver has "extension modules" to implement platform-specific functionality. These extension modules will fall under the license of the operating system on which they will run, thus forcing the complete device driver to this license as well (at compile-time). Here is a quick summary:
Dazuko Application Interface (on all platforms): BSD License Dazuko device driver (Linux): GPL License Dazuko device driver (FreeBSD): BSD License
Does Dazuko detect file accesses over Samba, Netatalk, and NFS?
Yes, yes, and yes. This allows you to develop software to monitor, regulate, or protect file access on your Samba, Netatalk, or NFS File Server.
Note for Netatalk: In order to work correctly with Dazuko, Netatalk must be compiled using the --with-did=cnid option.
Note for NFS: In order to work correctly with Dazuko, the NFS User Server must be used (not the NFS Kernel Server). The NFS Kernel Server communicates over sockets directly from the kernel, thus bypassing Dazuko.
I don't know anything about compiling kernels. Can I just download a pre-compiled binary of Dazuko?
One of the greatest advantages of free operating systems is also for many a problem. That is, they can be customized to support exactly the hardware and features you desire thereby maximizing your system performance (and satisfaction). However, since Dazuko must load into the kernel itself, Dazuko must be compiled with exactly the same code that your kernel was compiled with. With so many different kernel configuration possibilities, it is impossible to precompile a binary for each one.
Therefore, the only way you can get a compiled Dazuko is by compiling it yourself. In the future, operating system distributors may offer Dazuko as a pre-compiled binary, which has already been built for their pre-compiled kernel. SuSE Linux is one such system that already provides a pre-compiled Dazuko driver "out-of-the-box". This makes Dazuko much easier for people to use. Hopefully Dazuko can evolve (politically) to the point where this is more common.
What does Avira GmbH (formerly known as H+BEDV Datentechnik GmbH) have to do with Dazuko?
Avira GmbH is an anti-virus company based in Tettnang, Germany. In order to allow on-access file scanning for the GNU/Linux operating system, they developed Dazuko (called the "AvGuard kernel module" at the time). However, it was felt that releasing the module source code as free software would not only broaden the available user base, but also provide an opportunity to create a common interface for 3rd party file access control. Avira GmbH continues to fund developers to work on the Dazuko project. Although Dazuko is still relatively young, it has become the basis for several products and thus will continue to have development interest from the community.
Where did the name "Dazuko" come from?
Since Dazuko originated from a german company, it was felt that the name should somehow reflect something german. Dazuko's main function is to provide an interface for "file access control", or in german, "Dateizugriffskontrolle". Alles klar?
How is "Dazuko" pronounced?
'dah-tsu-ko'
Troubleshooting - general
What are the known issues with Debian GNU/Linux?
The "dazuko-source" package that is available through apt-get for the current stable release, sarge, is very old (1.2.2). It is recommended that you download the latest stable version from the Dazuko Downloads site.
For Debian unstable and testing, a more recent version of the "dazuko-source" package is available via apt-get.
John Ogness is the current maintainer for the Debian "dazuko-source" package.
For the current stable release, you can download the latest stable version as a Debian package here:
dazuko-source_2.3.3-1_all.deb
The Debian package requires "module-assistant". This will automatically compile and install Dazuko. Here is the procedure:
# apt-get install module-assistant # dpkg -i dazuko-source_2.3.3-1_all.deb # m-a a-i dazuko
You can then load the module with:
# modprobe dazuko
What are the known issues with SUSE Linux?
Recent SuSE distributions (SUSE Linux 10, SLES 10, SLED 10) include and use AppArmor by default, which is why other modules cannot access the LSM API. This means that it is not possible to use Dazuko in its default configuration on these systems (because Dazuko by default uses the LSM interface on Linux 2.6 kernels).
As of version 2.3.0 of Dazuko, you can use syscall hooking as an alternative to LSM for Linux 2.6 systems. If you require AppArmor, then you will need to use the syscall hooking method. This must be specified when configuring Dazuko:
$ ./configure --enable-syscalls --mapfile=/path/to/mapfile
The mapfile (System.map) is usually located in /boot and has the kernel version as a suffix.
SuSE 9.1
The default kernel settings for SuSE 9.1 make it difficult to install Dazuko. Here is a set of steps that you will have to take. It will be necessary to have at least kernel version "2.6.5-7.108". This may require an online update.
1. download and build Dazuko 2.3.3
$ tar xzvf dazuko-2.3.3.tar.gz $ cd dazuko-2.3.3 $ ./configure $ make
2. copy dazuko.ko to kernel module directory and refresh module dependencies
# cp dazuko.ko /lib/modules/`uname -r`/kernel/security # depmod -a
3. modify the boot parameters to disable NSA SELinux support
edit /boot/grub/menu.lst and add "selinux=0" to the end of the line:
kernel hd(... showopts
4. set Dazuko and Capability to be automatically loaded on startup
edit /etc/sysconfig/kernel and change the line:
MODULES_LOADED_ON_BOOT=""
to
MODULES_LOADED_ON_BOOT="dazuko capability"
5. reboot machine
What are the known issues with Fedora Core Linux?
A HOWTO for Fedora Core 4 was written by John Flanigan.
A HOWTO for Fedora Core 3 was written by Misu Moldovan.
Linux Default Capabilities are built into the kernel. Capabilities must be built as a module in order to work with Dazuko. This is because the "capabiltity" module does not support stacking.
Assuming you are using a fresh install of Fedora Core 2 and you have installed the kernel sources, here is a quick step-by-step procedure to installing Dazuko:
change to kernel source directory
# cd /usr/src/linux-`uname -r`
copy in the current kernel configuration
# cp /boot/config-`uname -r` .config
configure the kernel, change capabilities to be a module
# make menuconfig Security options -> Default Linux Capabilities <M>
exit, saving changes
build the kernel
# make
install kernel modules
# make modules_install
install kernel
# make install
build dazuko
# cd <path-to-dazuko-source> # ./configure --kernelsrcdir=/usr/src/linux-`uname -r` # make
install dazuko kernel module
# cp dazuko.ko /lib/modules/`uname -r`custom/kernel/security # depmod -ae `uname -r`custom
reboot
# reboot
After the machine reboots you can load Dazuko with:
# modprobe dazuko
Fedora Core 2 doesn't use devfs so you will need to create the dazuko device:
# mknod -m 600 /dev/dazuko c 254 0
What are the known issues with Mandrake Linux?
A HOWTO for Mandrake 10.1 was written by Scott Grayban.
Mandrake 10.1 has two problems:
1. Linux Default Capabilities are built into the kernel. Capabilities must be built as a module in order to work with Dazuko. This is because the "capabiltity" module does not support stacking.
2. When you build your own kernel using Mandrake's kernel-source package, modules are installed in /lib/modules/2.6.8.1-10mdkcustom but the kernel goes by the original name of 2.6.8.1-10mdksmp. The easiest solution is to rename the "custom" modules directory to the name of the original directory.
Mandrake 10.0 has two problems:
1. Mandrake 10.0 does not have Security turned on in the default kernel (this is what generated all the error messages). It also means that you MUST rebuild the kernel with Mandrake 10.0.
2. After rebuilding the kernel, running "make modules_install" does not install the security modules.
If you know these problems, then it is possible to install Dazuko on Mandrake 10.0. Assuming you have installed the kernel-source package, here is the step by step procedure of what to do:
change to kernel source directory
# cd /lib/modules/`uname -r`/build
copy in the current kernel configuration
# cp /boot/config-`uname -r` .config
configure the kernel
# make menuconfig Security options -> Enable different security modules [*] Security options -> Default Linux Capabilities <M>
exit, saving changes
build the kernel
# make
install kernel modules
# make modules_install
create security module directory
# mkdir /lib/modules/`uname -r`/kernel/security
copy over security modules
# cp security/*.ko /lib/modules/`uname -r`/kernel/security
install kernel
# cp System.map /boot/System.map-`uname -r` # cp .config /boot/config-`uname -r` # cp arch/i386/boot/bzImage /boot/vmlinuz-`uname -r`
update lilo
# lilo
build dazuko
# cd <path-to-dazuko-source> # ./configure # make
install dazuko kernel module
# cp dazuko.ko /lib/modules/`uname -r`/kernel/security # depmod -a
reboot machine
# reboot
Since Mandrake 10.0 uses devfs, there is nothing more that you must do. After rebooting, you can load dazuko with:
# modprobe dazuko
You can have Dazuko automatically load at startup by adding "dazuko" to /etc/modprobe.preload
What are the known issues with Gentoo Linux?
There are no known problems with Gentoo Linux. If you are using Capabilities for Linux 2.6, make sure that Dazuko is loaded first, before Capabilities.
A Gentoo package of Dazuko is available here.
How do I configure my Linux kernel source code?
There are several methods for configuring your source code. Once you are in the directory of your kernel source code, you can type:
$ make menuconfig
This brings up a ncurses-based configuration utility. Another option is a graphical (tcl-based) version:
$ make xconfig
Both configuration utilities do exactly the same thing. First, they read the contents of the .config file that is in the kernel source directory. After you choose "Save and Exit" all configuration information is saved in the .config file but also in the include/linux/autoconf.h file where the settings are actually used during compilation. This means that the important file for compiling Dazuko is autoconf.h.
However, most distributions do not keep a copy of the autoconf.h used when the kernel was compiled. Rather, they keep a copy of the .config file and save it as /boot/config-x.x.x. By copying this file over the .config file in the kernel source directory, then running the configuration utility and saving changes, you will have generated the autoconf.h that matches your kernel. This is what is meant by configuring the source code. Now Dazuko can be compiled and should insert properly into the kernel.
Note: It is assumed that you have the kernel source code that matches your running kernel. It is also assumed that you have a /boot/config-x.x.x file that matches your running kernel. Please pay attention to version numbers.
Note: It is not required that you run "make menuconfig" or "make xconfig" to generate autoconf.h from the .config file. Other options include:
$ yes "" | make config
or
$ make oldconfig
My system hangs during shutdown if Dazuko is loaded. Why?
When an application registers with Dazuko, the kernel will send all appropriate file access calls to that application. It is the responsibility of the application to allow or deny the access. If the application does not respond, the kernel will wait, causing what appears to be a lock up (i.e. your kernel can't open any files because it is waiting for the application to respond).
During shutdown, some operating systems issue a SIGSTOP which will freeze all running processes (for example, using the killall5 program under GNU/Linux). If one of these processes is registered with Dazuko, the problem mentioned above will occur. To avoid this problem, all applications using Dazuko should be terminated before the system shuts down. This is usually implemented with runlevel control scripts. Under GNU/Linux, another option is to add the /proc directory as an excluded path for Dazuko since killall5 needs to read files from this directory while all other processes are in the STOP state.
Dazuko seems to crash immediately after startup or as soon as an application tries to register itself. What is wrong?
This is almost certainly because you have compiled Dazuko with source code that does not match your running kernel. Even if you have the same kernel source files, they must also be configured exactly the same as your running kernel. The best (and safest) option is to compile and install a new kernel yourself. Then compile Dazuko using that same code. This way you can be sure that the running kernel matches Dazuko.
Linux: Most distributions offer their own version of the Linux kernel source code. You may prefer to build a new kernel from their provided source code rather than a "pure" Linux kernel. See FAQ for information about how to configure your Linux kernel source code.
With Linux 2.6 I am only getting ON_OPEN and ON_EXEC events. What is wrong?
For Linux 2.6, Dazuko uses the new LSM (Linux Security Model) security hooks. This does not fit well into the current design of Dazuko. For this reason Dazuko will report every access event as ON_OPEN or ON_EXEC (even if the events were something different). If your application requires each event to be properly identified with Linux 2.6, then it is currently suggested that you patch your kernel with RSBAC. Dazuko is included in the RSBAC patchset and is based on RSBAC API's. This allows Dazuko to correctly identify each access event type.
Other solutions for Linux 2.6 and Dazuko are currently being investigated and worked on. In the future this should not be a problem.
What are the known issues with the LSM (Linux Security Modules) system?
Traditionally the Dazuko module uses the LSM API on Linux 2.6 kernels, because this API was announced as the preferred method of interfacing with the kernel for the kind of tasks an on access scanner or activity logger needs to do. As Linux 2.6 development progressed this method turned out to be a maintenance headache since the LSM API changes with almost every kernel version. Recent uses of the LSM API by other projects like SE Linux and AppArmor even made it impossible for a second module like Dazuko to use the API as soon as one of these projects had their module loaded. Since newer distributions activate these modules by default and would not work correctly without them, trying to use Dazuko (or any other modules using the LSM API) changed from problematic to impossible.
One alternative is to employ an RSBAC enabled kernel. Dazuko interfaces cleanly with RSBAC while other applications don't suffer from its presence. But administering RSBAC is complex and can lead to being locked out of the machine when done inappropriately.
Another alternative is to hook syscalls on Linux 2.6 systems as well, just like it is done on Linux 2.2 and 2.4. The use of this method is discouraged by official kernel development policy, but it might be the only viable route to get your on access scanner working. Syscall hooking requires at least Dazuko version 2.3.0 and can be activated using the --enable-syscalls configuration option.
What are the known issues with Linux 2.6 syscall hooking?
Since interfacing with Linux 2.6 kernels via the LSM API turned out to be problematic and getting worse with every new stage of development, Dazuko version 2.3.0 (re)introduced the option to hook syscalls. Although this method is discouraged by the official kernel development policy, it is believed to work correctly and in a stable manner as it does on Linux 2.2 and Linux 2.4 systems.
It's essential to specify the System.map file at compile time (when the configure script is run) which correctly describes the kernel you want to load the module into. Using a module which was built based on incorrect information will risk your system's stability or break it completely.
Some distributions ship with a System.map file which incorrectly describes the data page the sys_call_table variable is residing at as being read only. Trying to act based on this information will result in a kernel BUG(). Since this situation can be detected at neither compile time nor run time, the Makefile created by the configure script may produce an IMPORTANT NOTICE warning that there may be problems when loading the module. The notice explains what could happen and what actions must be taken to successfully configure Dazuko.
Another method to run Dazuko on Linux 2.6 kernels without the LSM API being available is to employ an RSBAC enabled kernel.
