FAQ: 2 Troubleshooting - general
			Savannah GNU kernel.org coding Linux FreeBSD
Home About FAQ HOWTO Downloads Support Applications Developer Credits This project was initiated and is sponsored by Avira GmbH.			2.1 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 2.2 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 2.3 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 2.4 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 2.5 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. 2.6 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 2.7 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. 2.8 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. 2.9 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. 2.10 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. 2.11 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. FAQ - Index 3 Troubleshooting - "configure"