Kai-Cheung Leung | 7 Aug 2005 02:52
Picon

finding a sponser for the dazuko kernel module debian package

The dazuko website stated the difficulties in finding a sponser willing to
take the dazuko debian package to the repository.  However I have an idea
here:  You should contain the Debian development team of the clamav deb
package - another open-source anti-virus package which uses dazuko and I
guess they would be very keen to see dazuko entering the official debian
repository, and therefore will be very willing to look after the dazuko
kernel package if we let them to.

http://packages.qa.debian.org/c/clamav.html

However the only catch is that at present, the module in the dazuko-2.0.6
kernel package CANNOT stack properly with the capability module provided
in the kernel-image package.  Therefore we must clean this up before
seeking the clamav guys for sponsering.  This can be done by one of the
ways:

- fixing the stacking problem in the dazuko module (is this already done
on 2.1.0-pre7?)

- including a script in our package to ensure that dazuko is loaded before
capability

I wish you every success in getting dazuko into the Debian repository.

Kai-Cheung Leung (Mr.)
Dirk Vornheder | 8 Aug 2005 20:03
Picon

dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6

Hi !

dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6:

/privat/kernel/dazuko-2.1.0-pre7/dazuko_linux26.c:976: warning: implicit 
declaration of function `class_simple_destroy'
  LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.o
  Building modules, stage 2.
  MODPOST
*** Warning: 
"class_simple_create" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] undefined!
*** Warning: 
"class_simple_device_remove" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
undefined!
*** Warning: 
"class_simple_destroy" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
undefined!
*** Warning: 
"class_simple_device_add" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
undefined!
  CC      /privat/kernel/dazuko-2.1.0-pre7/dazuko.mod.o
  LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.ko
make[1]: Leaving directory `/privat/kernel/linux-2.6.13-rc5'
touch dummy_rule

Dirk
Gerhard Sittig | 9 Aug 2005 10:06
Picon

Re: dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6

* Dirk Vornheder <dirk.vornheder <at> piper-home.de> [2005-08-08 20:14]:
> 
> dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6:
> 
> /privat/kernel/dazuko-2.1.0-pre7/dazuko_linux26.c:976: warning: implicit 
> declaration of function `class_simple_destroy'
>   LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.o
>   Building modules, stage 2.
>   MODPOST
> *** Warning: 
> "class_simple_create" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] undefined!
> *** Warning: 
> "class_simple_device_remove" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
> undefined!
> *** Warning: 
> "class_simple_destroy" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
> undefined!
> *** Warning: 
> "class_simple_device_add" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko] 
> undefined!
>   CC      /privat/kernel/dazuko-2.1.0-pre7/dazuko.mod.o
>   LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.ko
> make[1]: Leaving directory `/privat/kernel/linux-2.6.13-rc5'
> touch dummy_rule

disclaimer: I don't speak for my employer here, I have my own mind

I don't know what drove the people to rename a struct every(!) driver
for Linux 2.6 needs.  In the middle of a 2.6 line.  There is no reason
to see what made this necessary, I hope it was not boredom ... :(  And
(Continue reading)

Dirk Vornheder | 22 Aug 2005 18:25
Picon

Re: dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6


> > dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6:
> >
> > /privat/kernel/dazuko-2.1.0-pre7/dazuko_linux26.c:976: warning: implicit
> > declaration of function `class_simple_destroy'
> >   LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.o
> >   Building modules, stage 2.
> >   MODPOST
> > *** Warning:
> > "class_simple_create" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko]
> > undefined! *** Warning:
> > "class_simple_device_remove" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko]
> > undefined!
> > *** Warning:
> > "class_simple_destroy" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko]
> > undefined!
> > *** Warning:
> > "class_simple_device_add" [/privat/kernel/dazuko-2.1.0-pre7/dazuko.ko]
> > undefined!
> >   CC      /privat/kernel/dazuko-2.1.0-pre7/dazuko.mod.o
> >   LD [M]  /privat/kernel/dazuko-2.1.0-pre7/dazuko.ko
> > make[1]: Leaving directory `/privat/kernel/linux-2.6.13-rc5'
> > touch dummy_rule
>
> disclaimer: I don't speak for my employer here, I have my own mind
>
> I don't know what drove the people to rename a struct every(!) driver
> for Linux 2.6 needs.  In the middle of a 2.6 line.  There is no reason
> to see what made this necessary, I hope it was not boredom ... :(  And
> on top it would have rang alarm bells in my mind to use a name like
(Continue reading)

Abhishek Nayani | 24 Aug 2005 19:57
Picon
Favicon

Stacking Issue (Possible Bug)

Hi,

When I stack another LSM module on top of dazuko, none of the hooks of
the second module are being called even though the registeration
succeeds. On looking at the registeration code, there seems to be a bug
(correct me if am mistaken) in dazuko_register_security function where
you  setup the hooks for the secondary module. The following patch fixes
the issue:

--- dazuko_linux26.c.old        2005-08-24 17:14:47.031585448 +0530
+++ dazuko_linux26.c    2005-08-24 17:15:14.500409552 +0530
 <at>  <at>  -691,7 +691,7  <at>  <at> 

               if (ext_func != def_func && daz_func == NULL)
               {
-                       daz_func = ext_func;
+                       *daz_func_p = ext_func;
               }

               daz_p += sizeof(void *);

Regards,
Abhi.
John Ogness | 28 Aug 2005 15:13
Picon

Re: dazuko 2.1.0-pre7 doesn't work under 2.6.13-rc6

Gerhard Sittig wrote:
> background: "somebody" renamed "struct simple_class" to "struct class"
> and changed the function names to allocate and release this data
> structure (without changing the interface at all).
> 
> You need to change the variable declaration and the associated
> function calls in dazuko_linux26.c.  This makes Dazuko compile again
> against 2.6.13 kernels.  Of couse it breaks builds on kernels up to
> 2.6.12.  So we end up with another #ifdef case.  Great job!

Hi,

I have added the changes to CVS. I just used ifdef's since it wasn't too
much code affected. Thanks for the patch.

John Ogness

--

-- 
Dazuko Maintainer
John Ogness | 28 Aug 2005 14:54
Picon

Re: Stacking Issue (Possible Bug)

Abhishek Nayani wrote:
> When I stack another LSM module on top of dazuko, none of the hooks of
> the second module are being called even though the registeration
> succeeds. On looking at the registeration code, there seems to be a bug
> (correct me if am mistaken) in dazuko_register_security function where
> you  setup the hooks for the secondary module.

Hi,

Yes, this was indeed a bug. I am surprised that it did not turn up
sooner. It has been fixed in CVS and will be available for the 2.1.0
release. Thank you.

John Ogness

--

-- 
Dazuko Maintainer
Tushar | 29 Aug 2005 17:30

meaning of set in struct dazuko_access

Hi all,
What is meaning of set_xxx fields in struct dazuko_accee ?
I have seen it almost for all fields of dazuko_access, e.g there is a
field "event" and "set_event", "filename" and "filename_set" etc.

Thanks
--
Regards,
Tushar
--------------------
It's not a problem, it's an opportunity for improvement. Lets improve.
--------------------------------------------------------------------------------
Is your computer free of Spyware and Viruses?
To check, download our latest FREE scanning toolkit from http://www.mwti.net/antivirus/mwav.asp
ober | 29 Aug 2005 18:22

OpenBSD port?

Has any work been done on an OpenBSD port?
If not I would like to take a stab at it.

Thanks in advance.

Ober Heim
John Ogness | 29 Aug 2005 19:35
Picon

Re: meaning of set in struct dazuko_access

Tushar wrote:
> What is meaning of set_xxx fields in struct dazuko_accee ?
> I have seen it almost for all fields of dazuko_access, e.g there is a
> field "event" and "set_event", "filename" and "filename_set" etc.

Hi,

It is not possible that all information is filled in with each event.
For example, there is no "mode" for ON_CLOSE events. This value only
makes sense for ON_OPEN events.

Since there is no guarenteed way to represent an unset value, each value
has a separate set_xxx boolean. If the boolean is set to false, then
Dazuko was not able to determine a value for that item.

For example, if uid == 0 and set_uid != 0, then you know that the event
was triggered by a root process. But if uid == 0 and set_uid == 0, then
this means that Dazuko was unable to determine which user triggered the
event.

In summary, the field XXX only has meaning if set_XXX is nonzero.

John

--

-- 
Dazuko Maintainer

Gmane