headers
John Ogness | 6 Aug 2006 21:13
Favicon

2.2.2 released

Hi,

The new latest official stable version 2.2.2 has been released. Aside
from a compiler error with the FreeBSD port, the differences since 2.2.1
have only included small improvements for Linux 2.6 version detection as
well as the usual changes to keep up with the latest Linux 2.6 API changes.

This will be the last 2.2.x release. Future development will now focus
on stabilizing 2.3.x (with Linux 2.6 syscall hooking). Be aware that the
Linux 2.6 syscall hooking solution is only a "bridge solution" until
Dazuko 3.0 with DazukoFS is ready.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
John Ogness | 13 Aug 2006 01:21
Favicon

2.3.1-pre1 posted

Hi,

I have posted 2.3.1-pre1. This version is basically 2.2.2 with Linux 2.6
syscall hooking added. The syscall hooking has been improved from the
2.3.0 release to better detect Linux kernel configurations and
appropriately configure Dazuko. Syscall hooking for Linux 2.6 is still
not the default method for capturing file events (it must be specified
using --enable-syscalls). Linux 2.6 systems should continue to use LSM
if possible and only fallback to syscall hooking if it is absolutely
necessary. Examples of this include:
- the user requires Novell's AppArmor
- the user requires SELinux
- the user cannot recompile the kernel and LSM is deactivated or
Capabilities are statically compiled

2.3.1-pre1 has been tested with Linux 2.6 on several architectures
(i686, ppc, amd64). On amd64 systems with syscall hooking, only file
events from 64-bit applications are detected. I plan to add support for
32-bit application events as well before the 2.3.1 release. Until then,
amd64 Linux 2.6 systems should use the (default) LSM interface.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
Tikka, Sami | 16 Aug 2006 21:42
Favicon

RE: 2.3.1-pre1 posted

Hello! Thanks for the new version!

Are the ON_EXEC events disabled on purpose when using syscall hooking on
Linux 2.6? It looks like the code supports exec events from syscall hooks.

I tweaked the configure script to allow ON_EXEC events and a quick test seems
to indicate they are working properly.

I guess if the script reads like:

	if [ $LINUX26_USE_SYSCALLS -eq 0 -a $CONFIG_X86 -ne 0 -a
$CONFIG_X86_64 -eq 0 ]
	then
		echo "NOOP: ON_EXEC allowed" > /dev/null

Then it can never say "ON_EXEC allowed" if LINUX26_USE_SYSCALLS has value 1.

-- Sami
Permalink | Reply | 1 comment |
headers
Tikka, Sami | 16 Aug 2006 22:23
Favicon

RE: 2.3.1-pre1 posted

One other thing that kind of bothers me is that dazuko (when using syscall
hooking) reports file accesses for non-existent files. 

For example, if a perl interpreter is looking for a file in its  <at> INC path
list, it simply tries to open the file in every one of those directories.
Dazuko faithfully reports all of these OPEN events.

One might think that a dazuko daemon simply needs to stat() the path given by
dazuko to figure out if the file exists or not, but that's not always
possible. The file might be on an NFS server or on some other file system
where you have to run in the context of the user to even see the file.

When dazuko is using LSM, it only reports OPEN and EXEC events for success
file opens or executions, which makes life a bit easier for the dazuko
daemon.

Could dazuko allow the open syscall to first complete and only if it is
successful, ask the dazuko daemon if the result can be returned to the user
or not?

-- Sami
Permalink | Reply | 501 comments |
headers
John Ogness | 16 Aug 2006 22:49
Favicon

Re: 2.3.1-pre1 posted

Tikka, Sami wrote:
> Are the ON_EXEC events disabled on purpose when using syscall hooking on
> Linux 2.6? It looks like the code supports exec events from syscall hooks.
> 
> I tweaked the configure script to allow ON_EXEC events and a quick test seems
> to indicate they are working properly.

You are right. Thanks for pointing this out. Since I do all development on:

Linux 2.6 (ppc)
Linux 2.6 (x86_64)
Linux 2.4 (i686)

I didn't actually have a chance to test the situation with:

Linux 2.6 (i686)

I have made the change in CVS and it will be included in the next
pre-release. It's actually a bit tricky, which is why I decided to use
NOOP cases to help simplify the logic. The new version also includes
comments for each case. ;)

$ env CVS_RSH="ssh" cvs -z3 \
-d:pserver:anonymous <at> cvs.savannah.nongnu.org:/sources/dazuko \
co dazuko

John Ogness

--

-- 
Dazuko Maintaier
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 16 Aug 2006 23:00
Favicon

Re: 2.3.1-pre1 posted

Tikka, Sami wrote:
> One other thing that kind of bothers me is that dazuko (when using syscall
> hooking) reports file accesses for non-existent files. 

It's interested that you complain about this. This is actually a feature
(which was a *lot* of work) which was introduced in Dazuko 2.0.3 for
FreeBSD 4 and later ported to FreeBSD 5 and Linux 2.4 for Dazuko 2.1.0.
Since the Linux 2.6 syscall hooking is based on the Linux 2.4 codebase,
it naturally also has this feature.

The feature was added because people wanted to know about events
*before* files are opened (probably to implement some form of user
rights management).

> When dazuko is using LSM, it only reports OPEN and EXEC events for success
> file opens or executions, which makes life a bit easier for the dazuko
> daemon.

This is because LSM doesn't provide information for files that do not
exist. Since Dazuko is supposed to report all events, I actually
consider this a bug for Dazuko with LSM.

> Could dazuko allow the open syscall to first complete and only if it is
> successful, ask the dazuko daemon if the result can be returned to the user
> or not?

Actually, Dazuko knows well before the real open() that the file doesn't
exist. Dazuko does a lot of work to figure out what the path *will* be.
It would be quite simple to move this logic behind an #ifdef and provide
a configure option for it. But I do not want to turn it off by default
(Continue reading)

Permalink | Reply | 501 comments |
headers
John Ogness | 21 Aug 2006 15:39
Favicon

2.3.1-pre2 posted

Hi,

I have posted 2.3.1-pre2, which fixes the configuration error on Linux 2.6
systems pointed out by Sami Tikka. I also expanded on the warning/notice
that appears when using syscalls with Linux 2.6 and the kernel is detected
as read-only.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
John Ogness | 29 Aug 2006 17:11
Favicon

2.3.1-pre3 posted

Hi,

I received a patch for the configure script from SUSE to allow Dazuko to be
built by their automated systems. The configure script now has an additional
option --kernelobjdir that can point to where the kernel build source files
are located. This was previously possible with the --kernelsrcdir option.
However, on some distributions the source dir and the object (build source)
dir are not the same.

The new changes shouldn't affect systems where the configure script
correctly worked before.

Unless problems are reported this week, 2.3.1 will become the new official
stable version next week.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 4 comments |
headers
John Ogness | 29 Aug 2006 17:31
Favicon

Re: Dazuko module packaging in Linux distributions

[ I have CC'd my answer to the dazuko-devel mailing list because of the
(possibly) interesting content. ]

Hi Eneko,

Here are some answers to your questions/comments.

Eneko Lacunza wrote:
> Have you ever tried to submit Dazuko to upstream Linux kernel tree?

No, but I have talked to many "important" kernel developers about it. The
current version of Dazuko would never be accepted into the mainline because:

1. LSM is on its way out of the kernel. It is a flawed and ugly interface
that should never have been created. For this reason, they do not want to
accept any new additional LSM modules in the mainline.

2. Dazuko (2.3.x) can use syscall hooking instead of LSM. But this is a
dirty hack that more resembles a rootkit than a security solution. This
method of event interception is heavily frowned upon.

The correct solution for intercepting events is using a stackable
filesystem. This is exactly what DazukoFS is. Although DazukoFS has been
working in a test environment for over a year, I have not had the time to
polish it up for an official preview release. Once DazukoFS is available
(3.0.x), we may have a chance of getting into the mainline kernel.

But there are several other parts of Dazuko that may need to be
significantly rewritten to better match the style of UNIX development. Here
I am talking specifically about the communication protocol between user
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tikka, Sami | 29 Aug 2006 23:39
Favicon

Some bugs detected

Hi John!

It seems to me that the options --enable-chroot-support and
--disable-chroot-support are reversed. If I want to enable chroot support, I
have to use --disable-chroot-support :)

We have also had a couple of kernel oopses with the latest dazuko but that
might be a configuration problem (using local dpath on smp machine and
such... I'm checking it out tomorrow.)

Then there is a problem with return values from dup and dup2 calls. Possibly
with close too. You should get a patch soon, tomorrow, I hope.

So, please hold off with 2.3 a couple more days.

-- Sami
Permalink | Reply | 1 comment |

Gmane