Re: thoughts on kernel security issues

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 01/13/05

  • Next message: selvakumar nagendran: "exporting /proc entry for module" 
    Date:	Wed, 12 Jan 2005 20:48:57 -0800 (PST)
To: Dave Jones <davej@redhat.com>

    On Wed, 12 Jan 2005, Dave Jones wrote:
    >
    > For us thankfully, exec-shield has trapped quite a few remotely
    > exploitable holes, preventing the above.

    One thing worth considering, but may be abit _too_ draconian, is a
    capability that says "can execute ELF binaries that you can write to".

    Without that capability set, you can only execute binaries that you cannot
    write to, and that you cannot _get_ write permission to (ie you can't be
    the owner of them either - possibly only binaries where the owner is
    root).

    Sure, that's clearly not viable for a developer or even somebody who
    maintains his own machine, but it _is_ probably viable for pretty much any
    user that is afraid of compiling stuff him/herself and just gets signed
    rpm's that install as root anyway. And it should certainly be viable for
    somebody like "nobody" or "ftp" or "apache".

    And I suspect there is almost zero overlap between the "developer
    workstation" kind of setup (where the above is just not workable) and
    "server or end-user desktop" setup where it might work.

    A lot of the local root exploits depend on being able to run code that
    doesn't come pre-installed on the system. A hole in a user-level server
    may get you local shell access, but you generally need another stage to
    get elevated privileges and _really_ mess with the machine.

    Quite frankly, nobody should ever depend on the kernel having zero holes.
    We do our best, but if you want real security, you should have other
    shields in place. exec-shield is one. So is using a compiler that puts
    guard values on the stack frame (immunix, I think). But so is saying "you
    can't just compile or download your own binaries, nyaah, nyaah, nyaah".

    As I've already made clear, I don't believe one whit in the "secrecy"
    approach to security. I believe that "security through obscurity" can
    actually be one valid level of security (after all, in the extreme case,
    that's all a password ever really is).

    So I believe that in the case of hiding vulnerabilities, any "security
    gain" from the obscurity is more than made up for by all the security you
    lose though delaying action and not giving people information about the
    problem.

    I realize people disagree with me, which is also why I don't in any way
    take vendor-sec as a personal affront or anything like that: I just think
    it's a mistake, and am very happy to be vocal about it, but hey, the
    fundamental strength of open source is exactly the fact that people don't
    have to agree about everything.

                            Linus
    -
    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: selvakumar nagendran: "exporting /proc entry for module"

    Relevant Pages

    • Huge Privacy Threats in Webmails and How Big Companies Handle them
      ... Most webmails have major security holes allowing people to hijack accounts ... the emails in his mailbox with 1 line of javascript in an e-mail and a 4 ...
      (Bugtraq)
    • UNICOS LOCAL HOLE ALL VERSIONS
      ... We are a collective group of security professionals who want to remain ... appropriate actions in fixing these gaping security holes, ... Possibly NQSD running in IBM and Solaris environments as well. ... In order to exploit this vulnerability, ...
      (Bugtraq)
    • Re: The mother of all XP holes?, part II
      ... > If a hacker has physical access to a machine then the data can be accessed ... Encrypting files is probably the ... In the twinkling of an eye, browser & spyware security ... >> holes could conceivably cause your prize data to be transferred across ...
      (comp.security.misc)
    • Re: The mother of all XP holes?, part II
      ... > If a hacker has physical access to a machine then the data can be accessed ... Encrypting files is probably the ... In the twinkling of an eye, browser & spyware security ... >> holes could conceivably cause your prize data to be transferred across ...
      (microsoft.public.security)
    • Re: The mother of all XP holes?, part II
      ... If a hacker has physical access to a machine then the data can be accessed ... The mother of all XP holes?, ... Imho really ugly browser security ... > their systems really secure. ...
      (comp.security.misc)