dazuko-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-help] RHEL5 x86_64 and syscall hooking?


From: John Ogness
Subject: Re: [Dazuko-help] RHEL5 x86_64 and syscall hooking?
Date: Sat, 12 Apr 2008 12:18:15 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix)

On 2008-04-11, Bill Lutton <address@hidden> wrote:
> Initially I tried configuring/building/loading Dazuko like this:
>    ./configure --enable-syscalls
>       --mapfile=/boot/System.map-2.6.18-el5
>    make clean; make
>    /sbin/insmod ./dasuko.ko
> At this point the system "hung".
>
> Having noticed the "Important Note:" in the first attempt I then tried:
>    ./configure --enable-syscalls
>       --mapfile=/boot/System.map-2.6.18-el5 --sct-readonly
>    make clean; make
>    /sbin/insmod ./dasuko.ko
> At this point the system "hung".
>
> I am using Dazuko-2.3.4.
> I am running a stock install of RHEL5 x86_64 from their ISOs
> (2.6.18-8.el5)
> uname -a: Linux RHEL564 2.6.18.8-el5 #1 SMP <date> x86_64 x86_64
> x86_64 GNU/Linux
> Note: got same results with the stock RHEL5.1 x86_64 ISOs
>       (2.6.18-53.el5).

I know that Red Hat has modified their kernel to prevent syscall
hooking. (The change_page_attr() function was modified to not allow
requests to change read-only to read-write.) But I didn't think was
included in the 2.6.18 kernel. Perhaps the 64-bit version of their
kernel already includes this change.

> - Is there a set of config options that will allow Dazuko to do
>   syscall hooking on RHEL5 x86_64?

The "official" (from me) recommended method is to patch the kernel
using the new Linux 2.6 kernel patch:

http://www.dazuko.org/files/patch-linux26-dazuko-2.3.5-pre1.tar.gz

and then building a new kernel. (See the README included in the
package.) This allows Dazuko to be built statically in the kernel.

The syscall hooking for Linux 2.6 was not developed by me and I do not
want to spend time trying to make sure it hacks around the latest
Linux kernel hardening. If someone else wants to get it fixed, I will
gladly accept patches.

> - Should I be using a different version of Dazuko?

If you are willing to build a new kernel, the "Dazuko as kernel patch"
option is the best:

  - it doesn't modify existing kernel code
  - it doesn't use any "tricks" to get access to file access events
  - it is supported and recommended by me (the current Dazuko
     maintainer)

The only drawbacks (also mentioned in the README) are:

  - it requires building a new kernel
  - it is only possible to use SElinux _or_ Capabilities, but not both

> - Would it be helpful to provide logs of the config/build output?

Posting them to the dazuko-devel mailing list would probably be more
effective. That's the list where the developers are
registered. Perhaps someone will provide a fix.

> - I don't know how to get console output of the fault running in
>   VMWare but would be happy to try to get it if it would help (and
>   if someone could provide a pointer to how to set this up).

In VMWare I believe there is a configuration option to have serial
output redirected to a file on the host system. Then you just need to
boot the kernel with the console also redirected to the serial port
and it should be dumped to the file.

The kernel boot parameter would look something like this:

   console=ttyS0,9600n8

You can specify the boot parameter multiple times and the console will
be output to all of them:

   console=tty0 console=ttyS0,9600n8

John Ogness

-- 
Dazuko Maintainer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]