Re: kernel stack challenge

From: John Stoffel (stoffel_at_lucent.com)
Date: 04/05/04

  • Next message: Eyal Lotem: "Re: [coLinux-devel] coLinux benchmarks" 
    Date:	Mon, 5 Apr 2004 16:09:30 -0400
To: Sergiy Lozovsky <serge_lozovsky@yahoo.com>

    >>>>> "Sergiy" == Sergiy Lozovsky <serge_lozovsky@yahoo.com> writes:

    Sergiy> Basically there are two reasons.

    Sergiy> 1. Give system administrator possibility to change security
    Sergiy> policy easy enough without C programminig inside the kernel
    Sergiy> (we should not expect system administartor to be a kernel
    Sergiy> guru). Language of higher lavel make code more compact (C - is
    Sergiy> too low level, that's why people use PERL for example or
    Sergiy> LISP). Lisp was chosen because of very compact VM - around
    Sergiy> 100K.

    Why in god's name does this need to be in the kernel? This is purely
    a userspace issue, and the tool for managing the security policy
    should be completely in userspace.

    Under this design, /bin/ls would be a kernel module, and not a
    userspace tool!

    If you ever want to even think about getting this project into the
    kernel, you'll have to re-design what you're doing here, since there's
    absolutely no need for anything like this in the kernel.

    Sergiy> 2. Protect system from bugs in security policy created by
    Sergiy> system administrator (user).

    C'mon, GIGO will kill you from user space or from kernel space. What
    makes you think LISP will protect you?

    Sergiy> LISP interpreter is a LISP Virtual Machine (as Java VM). So
    Sergiy> all bugs are incapsulated and don't affect kernel.

    Then *WHY* does the LISP interpreter need to be in the kernel in the
    first place? Hint, you just said you wanted to protect the kernel...

    Sergiy> Even severe bugs in this LISP kernel module can cause
    Sergiy> termination of user space application only (except of stack
    Sergiy> overflow - which I can address). LISP error message will be
    Sergiy> printed in the kernel log.

    Hah! You just gave the number one reason why you don't want or need a
    LISP interpreter in the kernel yourself.

    John
       John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
             stoffel@lucent.com - http://www.lucent.com - 978-952-7548
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Eyal Lotem: "Re: [coLinux-devel] coLinux benchmarks"

    Relevant Pages

    • Re: kernel stack challenge
      ... > Sergiy> Basically there are two reasons. ... > change security ... > Sergiy> policy easy enough without C programminig ... > inside the kernel ...
      (Linux-Kernel)
    • Re: kernel stack challenge
      ... Sergiy> Root privileges (ability to send a signal to any process, ... Sergiy> access any file and so on) are encoded in the kernel. ... But that does not require a LISP interpreter in the kernel either. ... And you are also mistaking policy with a capability. ...
      (Linux-Kernel)
    • Re: kernel stack challenge
      ... > Sergiy> Root privileges (ability to send a signal to ... > kernel either. ... > And you are also mistaking policy with a capability. ...
      (Linux-Kernel)
    • Re: kernel stack challenge
      ... > I'm dying to know why you need a LISP interpreter ... > inside the kernel. ... Give system administrator possibility to change ... that's why people use PERL for example or LISP). ...
      (Linux-Kernel)
    • Re: kernel stack challenge
      ... Give system administrator possibility to change ... > administartor to be a kernel guru). ... > that's why people use PERL for example or LISP). ... Protect system from bugs in security policy created ...
      (Linux-Kernel)