Transat Jacques Vabre

_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/dazuko-devel

Re: [Dazuko-help] Dazuko and Linux 2.6

Hi,

Yes, I have been keeping my eye on 2.5/2.6. I am about to release Dazuko 
version 2.0, which has been a major achievement for Dazuko (and a *lot* 
of work). Once it is available, I will be able to start focussing on 
Linux 2.6 (and FreeBSD 5).

In 2.4 (and earlier) there was no way that you could implement your own 
file access security module without major patches to the kernel. As a 
result, Dazuko hooks the system call, thus allowing it to have first say 
for file accesses (without requiring kernel patches). Although this 
works, it fits more into the category of "hacking the kernel" rather 
than "securing the kernel".

With 2.5/2.6, Linux provides an interface for implementing your own file 
access security module. This means that Dazuko will no longer need to 
hook the system calls. Although this makes Dazuko's job easier, it will 
require me (or someone) to appropriately match the Linux 2.6 security 
API to Dazuko. I have seen several examples of this and it looks like 
getting the access information to Dazuko will be the easy part.

However, I have not yet looked at the virtual file system, chroot 
models, and local name lookups for the new kernel. I am a lot more 
worried that these (more complex) pieces have changed considerably. (I 
am assuming they've changed because they changed quite a bit from 2.2 to 
2.4.)

I will most likely start working on the 2.6 port in December. If you 
subscribe the the dazuko-devel mailing list, we can start tackling this 
issue together.

John Ogness

Michael Grigoriev wrote:
> Hi,
> 
> I've been considering using Dazuko to get file access/change notifications
> in my network filesystem [http://www.luminal.org/wiki/index.php/FunFS].
> 
> Dazuko would allow me subscribe to notifications on an entire subtree in one
> go instead of having to subscribe to every file, like FAM. It would also let
> me block attempts to open files long enough for me to possibly get an oplock
> on it, thus delaying access further giving the filesystem time for force any
> client with outstanding write cache to flush it. In other words, it would be
> really useful.
> 
> As I do most of my development on Linux 2.5/2.6, I started looking into
> porting Dazuko to it. But here's the problem: it appears that sys_call_table
> is no longer exported to the modules (starting with 2.5.41 I think).
> 
> Here's some related information I was able to find on LKML:
> [http://lists.insecure.org/lists/linux-kernel/2003/May/0788.html]
> 
> 
>>It's unexported because there is no correct use for it and that it can't
>>be used correctly either. Tell me which lock your module uses to protect
>>modifications to it? Tell me how you handle other modules trying to
>>overload the same syscall and those modules loading before your module but
>>then unloading while yours is still loaded?
>>
>>It's the wrong mechanism to do ANYTHING. Really.
> 
> 
> So I was wondering if you've looked at 2.6 support at all, and if you had
> any ideas about how to do it.
> 
> Thanks in advance.

--

-- 
Dazuko Maintainer

Re: [Dazuko-help] Dazuko and Linux 2.6

On Fri, Nov 14, 2003 at 08:49:22PM +0100, John Ogness wrote:
> In 2.4 (and earlier) there was no way that you could implement your own 
> file access security module without major patches to the kernel. As a 
> result, Dazuko hooks the system call, thus allowing it to have first say 
> for file accesses (without requiring kernel patches). Although this 
> works, it fits more into the category of "hacking the kernel" rather 
> than "securing the kernel".

Agreed.

> With 2.5/2.6, Linux provides an interface for implementing your own file 
> access security module. This means that Dazuko will no longer need to 
> hook the system calls. Although this makes Dazuko's job easier, it will 
> require me (or someone) to appropriately match the Linux 2.6 security 
> API to Dazuko. I have seen several examples of this and it looks like 
> getting the access information to Dazuko will be the easy part.

Interesting. It does look like the linux security modules provide a lot of
the same hooks Dazuko was trying to get from the system calls. I'll have to
experiment with them.

> However, I have not yet looked at the virtual file system, chroot 
> models, and local name lookups for the new kernel. I am a lot more 
> worried that these (more complex) pieces have changed considerably. (I 
> am assuming they've changed because they changed quite a bit from 2.2 to 
> 2.4.)

It's not too bad. With some hacking, I actually ported the most of it to 2.6
and had the entire thing at least compiling before I noticed the
sys_call_table problem. It's getting kind of ugly with 3 levels of ifdefs
though.... I am going to see if there is a better way of handling the
version dependent stuff.

Or maybe you would consider phasing out 2.2 support? I mean is there really
a lot people still using it?

> I will most likely start working on the 2.6 port in December. If you 
> subscribe the the dazuko-devel mailing list, we can start tackling this 
> issue together.

Sorry, I didn't notice that there was a dazuko-devel list, or I would have
posted to it to begin with.

--

-- 
Have fun,                              I believe that we'll conceive
Michael "mag" Grigoriev              To make in hell for us a heaven
mag <at> luminal.org                   A brave new world, a promised land
http://www.luminal.org               A fortitude of hearts and minds

_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/dazuko-devel

Re: Re: [Dazuko-help] Dazuko and Linux 2.6

Hi,

> It's not too bad. With some hacking, I actually ported the most of it to 2.6
> and had the entire thing at least compiling before I noticed the
> sys_call_table problem. It's getting kind of ugly with 3 levels of ifdefs
> though.... I am going to see if there is a better way of handling the
> version dependent stuff.

One of the things I will be doing is getting rid of the #ifdefs within 
the code. This can be done by defining empty, do-nothing items for the 
versions that do not have these items. I would like the actual code to 
reflect the 2.6 version and use defines at the top so that 2.2 and 2.4 
will work with that code.

> Or maybe you would consider phasing out 2.2 support? I mean is there really
> a lot people still using it?

I am still getting requests to port to 2.0. :)

John Ogness

--

-- 
Dazuko Maintainer

Dazuko und RoutiX

Hallo,

 

eins Vorweg, great work!

 

kürzlich sind wir auf eure Seite gestossen als wir clamav um eine Funktion erweitern wollten.

 

Wir Schreiben momentan an einem Linux System names RoutiX, einem High-End-Live Server System

und da kam dazuko uns grad recht

 

Wir verwenden dazuko mittlerweile für mehrere Samba Access Control Vorgänge, für die Eigenentwicklung

rtx-firewall und um dem Endbenutzer vor der unabsichtlichen Zerstörung von wichtigen Systemdateien zu schützen.

 

Freuen würden wir uns, wenn wir in eurer Application-Liste stehen würden mit RoutiX und fragen im Gegenzug gleich,

ob es euch etwas ausmacht, wenn wir auf eure Seite verlinken?

 

MfG

O. Welter

 

<RoutiX Engineering>

_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/dazuko-devel

Re: Dazuko und RoutiX

Hi,

Sure, I would be happy to add a link. Just give me the address and some 
text that I can say about it.

John Ogness

Christian Thomas wrote:
> 
> Hallo,
>  
> eins Vorweg, great work!
>  
> kürzlich sind wir auf eure Seite gestossen als wir clamav um eine 
> Funktion erweitern wollten.
>  
> Wir Schreiben momentan an einem Linux System names RoutiX, einem 
> High-End-Live Server System
> und da kam dazuko uns grad recht 
>  
> Wir verwenden dazuko mittlerweile für mehrere Samba Access Control 
> Vorgänge, für die Eigenentwicklung
> rtx-firewall und um dem Endbenutzer vor der unabsichtlichen Zerstörung 
> von wichtigen Systemdateien zu schützen.
>  
> Freuen würden wir uns, wenn wir in eurer Application-Liste stehen würden 
> mit RoutiX und fragen im Gegenzug gleich,
> ob es euch etwas ausmacht, wenn wir auf eure Seite verlinken?
>  
> MfG
> O. Welter
>  
> <RoutiX Engineering>

Re: Dazuko and Linux 2.6

Hi,

I have started working on the port to the 2.6 Linux Kernel. I have been 
doing a lot of reading and tests using the new LSM stuff. It is 
amazingly easy. The main problems I am having is the all the tons of 
warnings and errors I am getting from the other stuff.

Michael, you mentioned that you had successfully compiled Dazuko for 2.6 
(except for the system call stuff). Is it possible you could submit your 
version of the code? With your fixes and my knowledge of LSM's it should 
be fairly easy to get the 2.6 port finished.

John Ogness

John Ogness wrote:
> Hi,
> 
>> It's not too bad. With some hacking, I actually ported the most of it 
>> to 2.6
>> and had the entire thing at least compiling before I noticed the
>> sys_call_table problem. It's getting kind of ugly with 3 levels of ifdefs
>> though.... I am going to see if there is a better way of handling the
>> version dependent stuff.
> 
> 
> One of the things I will be doing is getting rid of the #ifdefs within 
> the code. This can be done by defining empty, do-nothing items for the 
> versions that do not have these items. I would like the actual code to 
> reflect the 2.6 version and use defines at the top so that 2.2 and 2.4 
> will work with that code.
> 
>> Or maybe you would consider phasing out 2.2 support? I mean is there 
>> really
>> a lot people still using it?
> 
> 
> I am still getting requests to port to 2.0. :)
> 
> John Ogness

--

-- 
Dazuko Maintainer

Linux 2.6

Hi,

Over the weekend I set up a Linux 2.6-test11 system and began porting
Dazuko. Everything went fairly smoothly. I was able to compile Dazuko as
a security model, insert it into the kernel, and print out access
events. What still remains to do is:

1. setting up the /dev/dazuko device
This is a bit tricky because I have not yet learned how this is done in
the new kernel. devfs is apparently now obsolete, meaning I am supposed
to use sysfs? I need to do a lot of reading to find out about this out.

2. implementing wait_queues, mutexes, name structures, etc
Although the structures themselves do not appear to have changed too
much, I need to go through and make sure I can achieve the same
functionality with the new 2.6 stuff.

3. security model testing
One of the problems I am having with the new security model is that I am
not sure which hooks I am supposed to use. For example, I am concerned
that I will not be able to distinguish between ON_OPEN and ON_CLOSE
events. I will continue testing the various hooks out until I find the
ones that make me happy. :)

If anyone has any good information/HOWTO's about sysfs (or how devices
*should* be implemented under Linux 2.6) I would appreciate it.

John Ogness

--

-- 
Dazuko Maintainer

Re: Linux 2.6

On Mon, Dec 01, 2003 at 03:12:51PM +0100, John Ogness wrote:
> 1. setting up the /dev/dazuko device
> This is a bit tricky because I have not yet learned how this is done in
> the new kernel. devfs is apparently now obsolete, meaning I am supposed
> to use sysfs? I need to do a lot of reading to find out about this out.

I would recommend you use procfs for this. It's a simple and stable API that
has not changed from 2.4 to 2.6. For examples, see the Fuse project:
http://cvs.sourceforge.net/viewcvs.py/avf/fuse/kernel/dev.c?view=markup
(the relevant code is at the end of the file)

--

-- 
Have fun,
Michael "mag" Grigoriev                   I can make it all stop
mag <at> luminal.org                         The pain, this nightmare
http://www.luminal.org                That's all I can offer you

_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/dazuko-devel