Computers 'n Stuff: How to install AppArmor and Dazuko in OpenSuse 10.2

So you want to run Dazuko on a OpenSuse 10.2 System. However, This will not work out of the box, since Dazuko and Apparmor are using the same Linux Security Module (LSM) API. If you try to load dazuko while apparmor is running you'll get:

dazuko: failed to register
modprobe: FATAL: Error inserting dazuko (/lib/modules/xxxxx/weak-updates/dazuko.ko): Invalid argument

But there are ways to get Dazuko up and running and Apparmor even at the same time.

To run dazuko in OpenSuse 10.2 you have basically three options:

Unload the apparmor module before you load the dazuko module
recompile the dazuko module with syscalls enabeled (this doesen't work for chroot directories
recompile the kernel to export __d_path

Here I discribe all three of these options: How to do it and how to choose the right option.

Option 1:
This is the right option if you don't need AppArmor. You need to install Antivir using the ./install script that comes with the installation file which can be downloaded from avira. In addition you have to install the dazuko module using e.g. the Yast utility from the OpenSuse 10.2 distribution.

# modprobe -r apparmor
# modprobe dazuko
# avguard start

Use the Yast runtim configuration to make the changes permanent.

Since the default SuseLinux 10.2 default kernel is an SMP kernel for both single and multi CPU systems which does not export __d_path you there are only the following ways to get dazuko running together with AppArmor:

Option 2:
download the sources of the dazuko module and compile the module with syscalls enableled to circumvent the LSM API apparmor uses , local dpath disableled to avoid problems with the SMP kernel and disabbeled chroot support to get it running without __d_path. This is the right choice if you don't need chroot'd directories.

# ./configure --disable-local-dpath --disable-chroot-support --enable-syscalls --mapfile=/boot/System.map-`uname -r`
# make

now install and load the module

Option 3:
This assumes your in the folder wher the patch lives. Its in the extracted source folder of the dazuko moudIf you need support for chroot directories you have to patch kernel source e.g.

# patch /lib/modules/`uname -r`/build/fs/dcache.c patch_dpath.diff

and recompile the kernel in order to make him export __d_path. However this command seems not to work when you never build a kernel yourself. In this case use

# patch /usr/src/linux/fs/dcache.c patch_dpath.diff
# make clean
# make oldconfig
# make
# make modules_install
# make install

The dazuko module can only be compiled after compiling and loading the kernel so that the dazuko module will be compiled with the correct System.map. Else you get

dazuko: loaded, version=2.3.2
dazuko: no version for "__d_path" found: kernel tainted.

when loading the module

The Dazuko module can be configured and installed in this way to support chroot'd directories:

# cd /usr/lib/Antivir
# ./configure --disable-local-dpath --enable-syscalls --mapfile=/boot/System.map-`uname -r`
# mv /lib/modules/2.6.18.2-34-default/updates/dazuko.ko /lib/modules/2.6.18.2-34-default/updates/dazuko.ko.orig
# cp dazuko.ko /lib/modules/2.6.18.2-34-default/updates

everything is detailed in the Suse README of the AntiVir Distribution:

AntiVir README for users of the SUSE distribution
=================================================

There are issues with the on access scan feature on recent SUSE systems. More
thorough and up to date information is available at the www.dazuko.org site.
See the FAQ at http://www.dazuko.org/faq.shtml and the installation
instructions at http://www.dazuko.org/howto-install.shtml for more details.
The RELEASE_NOTES file that came with this installation package discusses the
issues with the latest Linux 2.6 kernels in more depth.

The on access scan feature of the AntiVir Server and AntiVir Workstation
products (commonly referred to as "Guard") runs on top of the Dazuko kernel
module. That's why it is essential that this module is available and fully
functional on a system where on access scans will be used.

By default Dazuko prefers the LSM API to interface with Linux 2.6 kernels to
capture file events. Unfortunately the AppArmor and SE Linux projects block
this API and prevent other modules from accessing it, which is why the
AppArmor and SE Linux features cannot be employed together with other LSM
using modules such as Dazuko.

In these setups it's necessary to switch to the so called syscall hooking
method to interface with a Linux 2.6 kernel. It's suggested to use at least
Dazuko version 2.3.1 and run the configure script with the --enable-syscalls
option. It's essential to specify a System.map file with the --mapfile=
option which exactly fits the kernel which the module gets built for.

Unfortunately there are System.map files which declare kernel data pages as
read only while they actually are not. Taking action at runtime based on this
information when it's incorrect leads to a kernel BUG() while not taking
action at runtime while the information is correct results in Oopses and
crashes. This situation cannot be detected by software without actually
running into the problem. Neither at build time nor at run time is it
possible to determine the correctness of this information.

At this point it's important that the administrator does know whether the
kernel data pages on this system actually are read only or whether they are
not and were wrongly declared so. With this information the Dazuko configure
script can be invoked with the appropriate options. Should this information
not be available, a test system should be used to try which approach works for
such a configuration (this is not suggested to be done on a production
system).

SUSE distributions usually do not have read only kernel data pages. Which is
why the Dazuko configure script assumes that the System.map information is not
correct and issues a warning message to this effect. Should loading a module
which was built this way result in a kernel BUG(), the module unfortunately
cannot be unloaded and the machine needs to be rebooted instead. The module
then needs to be built with the additional --sct-readonly flag passed to the
configure script.

and here:

==============================
README for Linux 2.6 kernels
==============================

In order to lookup full file paths (even in chroot environments), Dazuko
uses the kernel function __d_path(). Unfortunately this function is no
longer exported to kernel modules in the Linux 2.6 kernel.

Dazuko has its own copy of this function but unfortunately it is only safe
for UP (uni-processor or non-SMP) kernels. This is because the real __d_path()
function uses a kernel lock, which is not available to kernel modules.

If your kernel is not configured as SMP, then it is safe to use Dazuko's
copy of the __d_path() function. This is default.

If your kernel is SMP then you should _not_ use Dazuko's copy of __d_path().
You can disable Dazuko's local copy of __d_path() by configuring Dazuko with:

$ ./configure --disable-local-dpath

Since Dazuko requires __d_path(), your kernel will have to export it if you
disable the local copy. Some GNU/Linux distributions have a modified kernel
that does export this function. The "vanilla" Linux kernel does _not_ export
this function. You can check if your kernel exports this function with:

$ grep __d_path /proc/kallsyms

The results can be interpreted as:

xxxxx T __d_path <= exported xxxxx t __d_path <= not exported If you are running an SMP kernel and __d_path() is not exported, then you will have to modify your kernel source code to export the symbol and rebuild your kernel. The modification is very simply and can be made by using the included patch to modify the fs/dcache.c file. Here is an example: $ patch /lib/modules/`uname -r`/build/fs/dcache.c patch_dpath.diff The location of your Linux kernel source code may be different. Once you have patched the fs/dcache.c file, you can rebuild and install your kernel and kernel modules. If your GNU/Linux distribution doesn't export the __d_path() function, you may want to write them email suggesting that this function be exported in the next release. Note: As a workaround, Dazuko now offers the configuration option --disable-chroot-support. This will disable Dazuko from trying to resolve chroot'd filenames, thus making Dazuko safe for SMP kernels that do not export __d_path(). However, if this option is used, registered applications will only be able to work with chroot'd filenames if they resolve the filenames from within userland. If the application you plan to use with Dazuko requires handling chroot'd filenames (and you have an SMP kernel that cannot export __d_path()), then you should contact the application developer to make sure it supports this option.