Dazuko's 6th birthday (Wiki)

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Dazuko's 6th birthday (Wiki)

John Ogness-5
Hi,

Today marks 6 years of Dazuko. I am working to get the project
organized so that it can continue forward. One of the things I feel
will help this is to allow the community direct access to maintain the
website. With the constant release of new distributions and kernels,
Dazuko is in a constant state of change. Dazuko's only documentation
(the website) suffers the most from this.

As of right now Dazuko's site is based on the MediaWiki
software. Anyone who creates an account (and verifies their email) is
able to make changes to the site.

I have already moved over most of the information from the old site,
but there are still some things to do. There's also definate room for
improvement on the formatting.

However, I did manage to add two new pages that I think are helpful
(particularly for developers). The first is a "Roadmap" page, which
lists the next steps for the Dazuko project. This will help everyone
to know where Dazuko is headed.

The second is a "Related Work" page. This includes links to the many
kernel modules and communities that are doing the same type of work as
the Dazuko project. Right now a lot of people are doing the same thing
but in different ways. By putting everything together on a single
page, users and developers can have a clear overview about what is out
there.

This last year has been a difficult one for myself (as maintainer) and
the Dazuko project in general. There are a lot of changes happening
and it is necessary for the project to refocus on a positive
direction. For 2008 the main focus is moving towards Linux-mainline
acceptance (with DazukoFS).

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

jim burns
On Tuesday 05 February 2008 04:52:56 pm John Ogness wrote:
> However, I did manage to add two new pages that I think are helpful
> (particularly for developers). The first is a "Roadmap" page, which
> lists the next steps for the Dazuko project. This will help everyone
> to know where Dazuko is headed.
>
From the Roadmap:
1. release a version of Dazuko as a patch for Linux 2.6.24

Why a patch instead of a kernel module?
3. post experimental nullfs code

What is nullfs? Thanx.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

John Ogness-5
On 2008-02-06, jim burns <[hidden email]> wrote:
>> From the Roadmap:
>> 1. release a version of Dazuko as a patch for Linux 2.6.24
>
> Why a patch instead of a kernel module?

The current release of Dazuko uses LSM to intercept file access
events. As of 2.6.24, LSM modules may no longer be kernel
modules. They _must_ be statically compiled into the kernel.

I am nearly finished with the patch, which will allow someone to
easily add Dazuko to their kernel code and compile their kernel. The
only part of the existing kernel code that the patch touches are
Makefile and Kconfig files.

>> 3. post experimental nullfs code
>
> What is nullfs?

The current experimental release of DazukoFS is based on the stackable
filesystem templates from the FiST project. However, I am not
satisfied with the implementation in those templates. Instead I have
written a new stackable filesystem from scratch (with FiST and
ecryptfs for partial referencing).

The stackable filesystem is called nullfs and does nothing but stack
on top of an existing filesystem. This provides an excellent test to
make sure that the stackable filesystem is correctly implemented.

I think nullfs could be of value as part of the Linux kernel. It would
function not only for general stacking tests, but also provide an
example for others interested in writing stackable filesystems. For
the future it could evolve to be part of a stackable framework, from
which all stackable filesystems could use. But that would be a
longterm goal to reduce redundancy in the kernel.

If nullfs could become part of mainline, it would be very simple to
get dazukofs into mainline. (The difference between nullfs and
dazukofs are around 30 lines of code.)

Although nullfs is currently not completed, it already works very well
(better than the FiST-template, in my opinion). I want to get the
current work of nullfs out to the public so that people can begin
seeing what I am working on.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Bugzilla from alon.barlev@gmail.com
On 2/6/08, John Ogness <[hidden email]> wrote:
> On 2008-02-06, jim burns <[hidden email]> wrote:
> >> From the Roadmap:
> >> 1. release a version of Dazuko as a patch for Linux 2.6.24
> >
> > Why a patch instead of a kernel module?
>
> The current release of Dazuko uses LSM to intercept file access
> events. As of 2.6.24, LSM modules may no longer be kernel
> modules. They _must_ be statically compiled into the kernel.

This may impose a serious problem with distributions... I don't know
if I will be able to push this into Gentoo users this way, and Gentoo
are one of the easiest with regards to patching.

Alon.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

John Ogness-5
On 2008-02-08, Alon Bar-Lev <[hidden email]> wrote:
>> The current release of Dazuko uses LSM to intercept file access
>> events. As of 2.6.24, LSM modules may no longer be kernel
>> modules. They _must_ be statically compiled into the kernel.
>
> This may impose a serious problem with distributions... I don't know
> if I will be able to push this into Gentoo users this way, and
> Gentoo are one of the easiest with regards to patching.

Yes, it may cause problems for distributions. I am considering adding
a kernel parameter so that Dazuko can be dynamically activated at boot
(like SElinux). Then distributions would be able to include the patch,
but leave Dazuko disabled. Users could then easily enable it with
somthing like "dazuko=1" as a boot parameter.

The only alternative is to avoid LSM.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Bugzilla from alon.barlev@gmail.com
On 2/9/08, John Ogness <[hidden email]> wrote:
> Yes, it may cause problems for distributions. I am considering adding
> a kernel parameter so that Dazuko can be dynamically activated at boot
> (like SElinux). Then distributions would be able to include the patch,
> but leave Dazuko disabled. Users could then easily enable it with
> somthing like "dazuko=1" as a boot parameter.
>
> The only alternative is to avoid LSM.

What about the syscall and System.map workaround, someone had suggested this at:
http://bugs.gentoo.org/show_bug.cgi?id=207537

Maybe until 2.6.25 you come up with none LSM solution?

Alon.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Adam Jerome
In reply to this post by John Ogness-5
Sat, Feb 9, 2008 at  3:36 AM, John Ogness <[hidden email]> wrote:

> On 2008-02-08, Alon Bar-Lev <[hidden email]> wrote:
>>> The current release of Dazuko uses LSM to intercept file access
>>> events. As of 2.6.24, LSM modules may no longer be kernel
>>> modules. They _must_ be statically compiled into the kernel.
>>
>> This may impose a serious problem with distributions... I don't know
>> if I will be able to push this into Gentoo users this way, and
>> Gentoo are one of the easiest with regards to patching.
>
> Yes, it may cause problems for distributions. I am considering adding
> a kernel parameter so that Dazuko can be dynamically activated at boot
> (like SElinux). Then distributions would be able to include the patch,
> but leave Dazuko disabled. Users could then easily enable it with
> somthing like "dazuko=1" as a boot parameter.
>
> The only alternative is to avoid LSM.

FYI...

As for Novell/SuSE, I suspect that the work done by upstream to make
LSM static-link only will most likely be reverted for SLED/SLES 11.  
Meaning that LSM may continue to be a viable alternative for some time.

-Adam






_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Adam Jerome
In reply to this post by Bugzilla from alon.barlev@gmail.com
Feb 9, 2008 at  9:25 AM, in message, "Alon Bar-Lev" [hidden email]> wrote:

> On 2/9/08, John Ogness <[hidden email]> wrote:
>> Yes, it may cause problems for distributions. I am considering adding
>> a kernel parameter so that Dazuko can be dynamically activated at boot
>> (like SElinux). Then distributions would be able to include the patch,
>> but leave Dazuko disabled. Users could then easily enable it with
>> somthing like "dazuko=1" as a boot parameter.
>>
>> The only alternative is to avoid LSM.
>
> What about the syscall and System.map workaround, someone had suggested this
> at:
> http://bugs.gentoo.org/show_bug.cgi?id=207537
>
> Maybe until 2.6.25 you come up with none LSM solution?

FYI... the syscall table is now in "read-only" memory (upstream).  My vote is to
proceed with an LSM solution.

Of course, there may still be ways to hack the syscall codepath.  (Perhaps
a copy of the table in rw mem, and then redirect all syscall table references
to the rw copy;... etc.)

-adam




_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Bugzilla from alon.barlev@gmail.com
In reply to this post by Adam Jerome
On 2/11/08, Adam Jerome <[hidden email]> wrote:
> As for Novell/SuSE, I suspect that the work done by upstream to make
> LSM static-link only will most likely be reverted for SLED/SLES 11.
> Meaning that LSM may continue to be a viable alternative for some time.

Why was LSM modified to be static anyway?

Alon.


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

John Ogness-5
On 2008-02-11, Alon Bar-Lev <[hidden email]> wrote:
> Why was LSM modified to be static anyway?

http://lkml.org/lkml/2007/10/17/532


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

Adam Jerome
In reply to this post by Bugzilla from alon.barlev@gmail.com
Feb 11, 2008 at 12:14 PM, "Alon Bar-Lev" <[hidden email]> wrote:
> On 2/11/08, Adam Jerome <[hidden email]> wrote:
>> As for Novell/SuSE, I suspect that the work done by upstream to make
>> LSM static-link only will most likely be reverted for SLED/SLES 11.
>> Meaning that LSM may continue to be a viable alternative for some time.

That is a great question.  I am not sure I have the correct answer.

I do know that as the patch was being considered, Linus called for anyone
to refute the patch; and more specifically, he asked all projects that were
using LSM (that might be considering submission of their project
upstream at some point) to make them self known.  From what I saw, no
such projects made themselves known.

From a (rather hard-core) upstream perception, the only one using LSM
was SELinux (being that they were the only ones who had submitted
upstream).  So, (as the logic went), if SELinux is the only valid LSM
client and SELinux is a compiled-in kernel enhancement, why leave a
dynamic link LSM interface open which might be a security threat itself?

So, in the name of "nobody else will fess up to using LSM" and "A
dynamic LSM interface is a security threat", Linus accepted the patch
which closed LSM to dynamically loaded modules.

I feel that this action was hasty; that making LSM a static-link-only
interface is very short-sited.  It shut the door to many up-and-comming
security related projects (that were just not ready for submission upstream).
This action obviously gives an unfair advantage to the SELinux camp.  

-adam






_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

John Ogness-5
In reply to this post by Bugzilla from alon.barlev@gmail.com
On 2008-02-09, Alon Bar-Lev <[hidden email]> wrote:
> What about the syscall and System.map workaround, someone had
> suggested this at: http://bugs.gentoo.org/show_bug.cgi?id=207537

One of the problems with syscall hooking is that the kernel
development community is actively working to protect the syscall table
from being hooked. Red Hat in particular has been working on
preventing this since 2002. Every time the kernel is changed, some
workaround is found to make it work. It is a "cat and mouse" game that
nobody wants to play. Aside from the fact that syscall hooking is
technically frowned upon, it is also too much maintenance work for me
to be interested. (Syscall hooking support for Linux 2.6 was mostly
implemented by various developers from F-Secure and not by me.)

> Maybe until 2.6.25 you come up with none LSM solution?

The only solution I am interested in is a stackable filesystem. But I
am open to accept patches if someone else wants to find some other
solution.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dazuko's 6th birthday (Wiki)

John Ogness-5
In reply to this post by Adam Jerome
On 2008-02-12, Adam Jerome <[hidden email]> wrote:

> I do know that as the patch was being considered, Linus called for
> anyone to refute the patch; and more specifically, he asked all
> projects that were using LSM (that might be considering submission
> of their project upstream at some point) to make them self known.
> From what I saw, no such projects made themselves known.
> [...]
> I feel that this action was hasty; that making LSM a
> static-link-only interface is very short-sited.  It shut the door to
> many up-and-comming security related projects (that were just not
> ready for submission upstream).  This action obviously gives an
> unfair advantage to the SELinux camp.

I feel that the decision was a correct one. The Linux kernel community
does _not_ want a lot of external security modules floating
around. They _want_ people to work _with_ the community to develop
their security modules in mainline.

The fact that LSM was so easy to use allowed a lot of people to
develop modules that may or may not offer real security and definately
were not compatible with one another. This has resulted in a chaos,
which has hurt the end users more than anyone else. LSM probably
should never have been made an "exported" API in the first place.

Dazuko was developed originally as a closed-source solution. After the
source was freed, Dazuko development continued to be developed
completely independent from the Linux kernel. I believe that this was
a mistake and one that needs to be corrected if Dazuko is to have a
future. Dazuko _must_ work to become part of mainline.

The catch is that Dazuko has become quite a large project that has
evolved to be more complex than it need be. Such a large, complex
project has no chance for mainline acceptance. This means that Dazuko
needs to be slowly integrated into mainline (piece by piece) and
making sure each piece is as clean and maintainable as possible.

If other LSM-based projects are serious about being accepted, they
will do the same.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel