Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-timeauthentication of binaries

Quoting Ulrich Drepper (drepper@xxxxxxxxx):
On 4/25/06, Axelle Apvrille <axelle_apvrille@xxxxxxxx> wrote:
1- "does this also prevent people writing their own
elf loader in a bit of perl and just mmap the code"

I'm not sure to exactly understand what you mean:

- if you mean writing an application able to read &
'interpret' an ELF executable: again, I think DigSig
will prevent this, because when you mmap the code,
this calls (at kernel level) do_mmap which triggers an
LSM hook called file_mmap. And we implement checks in
that hook...

- if you mean modifying the ELF loader so that do_mmap
/ file_mmap aren't called, well you'll need to hack
the kernel, won't you ?

- finally, note you also have choice not to sign this
elf loader of yours. If it isn't signed, it won't ever
run ;-)

No, there no problem writing a loader. All you need is to create
anonymous mappings. Via mmap, maybe on the stack, some heaps are
still executable. Then you load the code, fix it up for the address,
and be done. The kernel cannot and will not prevent a read(2) call on
the binary. That's all that's needed. And without the SELinux
support in place you cannot prevent non-exec memory creation and even

BS - you can stack another LSM to prevent that.

Or, stack it with SELinux. I've tested that combination before with no
problems.

then, some people need it (jvms, OpenGL libs, etc) to generate code on
the fly. So it's never completely ruled out. Again, look at the code
in http://people.redhat.com/drepper/selinux-mem.html.

Given you have executable anonymous memory it is a one-time small
effort to write a loader and you're done. Nothing your signature

A one time effort to write it *and sign it*.

You could just as well write it and give it it's own domain with {
execheap execmem execstack execmod } permissions.

detection code can do about it. This is snake oil.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-timeauthentication of binaries
    ... elf loader in a bit of perl and just mmap the code" ... if you mean modifying the ELF loader so that do_mmap ... the kernel, won't you? ... support in place you cannot prevent non-exec memory creation and even ...
    (Linux-Kernel)
  • Re: mmap()
    ... >> 2 GB for stack and data size and edited the ... > default MAXDSIZ in my kernel)? ... I have verified that I can mallocmuch more memory that I can mmap ...
    (freebsd-performance)
  • Re: SuSE 7.3 : Kernel 2.4.10-4GB Bug
    ... Subject: SuSE 7.3: Kernel 2.4.10-4GB Bug ... Jakub Jelinek: ELF loader cleanups ... Jakub Jelinek: handle more ELF loading special cases ... Vendors wishing to backport patches into their kernels may wish to start ...
    (Bugtraq)
  • Re: [BROKEN PATCH] kexec for ia64
    ... But all they need are the ia64 bits of the ELF loader, ... Sort of fundamentally they are arch dependent. ... was targeted for a kernel without device_shutdown, ...
    (Linux-Kernel)
  • Re: [BROKEN PATCH] kexec for ia64
    ... But all they need are the ia64 bits of the ELF loader, ... > was targeted for a kernel without device_shutdown, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)