Re: Linux Kernel Security - Can it ever be 100%

From: Joey Hess (joeyh_at_debian.org)
Date: 12/06/03

  • Next message: Tom: "Re: Linux Kernel Security - Can it ever be 100%" 
    Date: Fri, 5 Dec 2003 23:43:23 -0500
To: debian-user@lists.debian.org

    Dave wrote:
    > Recent discussions in this group have raised as many questions for me as
    > they have answered, and raised doubts in my mind that the security of the
    > Linux kernel will ever be as good as I would like it to be. Is there a
    > fundamentally simple and 100% effective way to stop kernel exploits, or
    > will we be forever locked in a race between white hats and black hats?

    I'm afraid that there is a stock answer one receives when one asks
    questions like these on internet discussion lists. I won't bother to
    give it as I'm sure someone will before this mail propigates out.

    > I am still hoping kernel security will eventually be as good as the security
    > of a typical microprocessor instruction set. Throw a trillion bad inputs
    > at an x86 microprocessor, and you will never take over the "supervisor"
    > mode.

    Touching faith in hardware. Pity it doesn't live up to it. Hardware is
    put together by humans, using tools increasingly similar to the tools we
    use to write software, and humans make mistakes. There has been at
    least one mistake in Intel hardware which had effects as bad as you
    describe; I alluded to it in my earlier mail.

    I think you'll find that a trillian bad inputs thrown at the linux
    kernel or any random setuid program are also unlikly to get you root
    (maybe a crash if you're lucky), but careful study and a targeted attack
    has much better luck.

    > [1] Are the parts of the kernel that need to be fast the same parts that
    > read input from a user process,

    It depends on your workload, but under most, yes, syscalls are very
    frequent, and their speed is essential. Something as simple as getting
    the current time, which is perhaps the most common syscall on desktop
    machines, involves passing a pointer to the kernel for it to write the
    time to. (However, that syscall has been at least partly moved to user
    space; I forget the details).

    > or can we say that 95% of user inputs can
    > be passed through robust, standardized validation routines with no
    > performance degradation noticeable to the user? e.g. When the user
    > process says "Here's a pointer to my data.", should a kernel routine just
    > start stuffing a buffer, or call a common routine that at leasts checks
    > the length of the data to be stuffed. If "blind buffer stuffing" were
    > limited to just those routines where this transaction was time-critical,
    > then those few routines could get a lot of scrutiny for buffer overflows.

    I think that you'll find that all accesses of data in user space by
    syscalls goes through a set of functions that do size checking and other
    checks. I think you'll find that the kernel is not in the business of
    trading off correctness for speed and instead they generally manage
    both. Except, of course, when mistakes are made.

    Some of the relevant code is several of the files in kernel/ or
    fs/read_write.c/open.c, depending on which syscalls you're intrested in,
    plus linux/arch/i386/lib/usercopy.c, and
    linux/include/asm-i386/uaccess.h

    If you're looking for more assurance than that, I think you'll quickly
    fall into a need for formal correctness proofs, which are probably very
    difficult for something with the scope of the linux kernel.

    > [3] I'm not sure what is meant by "tainted inputs" here. My guess is we
    > are talking about inputs that would pass simple validation checks (string
    > lengths, number ranges, membership in an allowed set) but still cause a
    > subtle problem later. It seems like that kind of problem would be very
    > unlikely, and almost impossible to exploit for anything other than causing
    > a crash. I'm comparing this situation to the comparable vulnerability with
    > microprocessor instruction sets, and we don't see that happening.

    There is vast potential for that kind of thing, particularly in the
    syscalls that manipulate files. Lots of potential for races, many ways
    to add malicious data to try to mess the kernel up (think of chains of
    recursive symlinks, for example). There have been many fixes in this
    area in the past. 

    -- 
see shy jo



    -- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Tom: "Re: Linux Kernel Security - Can it ever be 100%"

    Relevant Pages

    • Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
      ... basically the exact same setup that Zach does in his fibril stuff, ... They can be applied to kernel threads just as much. ... i should have said explicitly that to flip user-space from one kernel ... That would allow the submission of new syscalls ...
      (Linux-Kernel)
    • Re: mysql scaling questions
      ... same file which is running into exclusive locking in the kernel ... Isn't this common for software developed for Linux? ... Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary trips ... Also I believe glibc caches getpid() in libc (again that ...
      (freebsd-performance)
    • Re: [PATCH 08/12] add trace events for each syscall entry/exit
      ... kernel threads, like invoking them with int 0x80. ... behaviour to change soon and have explicit syscalls interrupts done ... Is it worth it to trace kernel threads, maintain their tracing ... A creation of a thread is the result of the kthreadd thread fork. ...
      (Linux-Kernel)
    • Re: [PATCH 08/12] add trace events for each syscall entry/exit
      ... kernel threads, like invoking them with int 0x80. ... behaviour to change soon and have explicit syscalls interrupts done ... Is it worth it to trace kernel threads, maintain their tracing ... A creation of a thread is the result of the kthreadd thread fork. ...
      (Linux-Kernel)
    • Linux Kernel Security - Can it ever be 100%
      ... Linux kernel will ever be as good as I would like it to be. ... am still hoping kernel security will eventually be as good as the security ... read input from a user process, or can we say that 95% of user inputs can ... standardized validation routines with no ...
      (Debian-User)