Feb 9, 2008 at 9:25 AM, in message, "Alon Bar-Lev" [EMAIL PROTECTED]> wrote: > On 2/9/08, John Ogness <[EMAIL PROTECTED]> 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 [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
