public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Ingo Molnar <mingo@elte.hu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	pageexec@freemail.hu, Andi Kleen <andi@firstfloor.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, tglx@tglx.de, hpa@zytor.com
Subject: Re: [patch] Add basic sanity checks to the syscall execution patch
Date: Fri, 5 Sep 2008 22:41:34 +0200	[thread overview]
Message-ID: <20080905204134.GI19337@1wt.eu> (raw)
In-Reply-To: <20080905114233.GA27878@elte.hu>

On Fri, Sep 05, 2008 at 01:42:33PM +0200, Ingo Molnar wrote:
> The far better solution would be to insert uncertainty into the picture: 

till there OK :-)

> some sort of low-frequency watchdog [runs once a second or so] that 
> tries to hide itself from the general kernel scope as much as possible, 
> perhaps as ELF-PIC code at some randomized location, triggered by some 
> frequently used and opaque kernel facility that an attacker can not 
> afford to block or fully filter, and which would just check integrity 
> periodically and with little cost.

"can not" above is the unrealistic requirement unfortunately.

> When it finds a problem it immediately triggers a hard to block/filter 
> vector of alert (which can be a silent alarm over the network or to the 
> screen as well).
> 
> that method does not prevent rootkits in general (nothing can), but sure 
> makes their life more risky in practice - and a guaranteed livelihood 
> and risk reduction is what typical criminals are interested in 
> primarily, not whether they can break into a particular house.
> 
> If we implement it then it should not be present in distro .config's, 
> etc. - it should be as invisible as possible - perhaps only be part of 
> the kernel image .init.data section in some unremarkably generic manner. 

Then they will simply proceed like this :
  - patch /boot/vmlinuz
  - sync
  - crash system

=> user says "oh crap" and presses the reset button. Patched kernel boots.
   Game over. Patching vmlinuz for known targetted distros is even easier
   because the attacker just has to embed binary changes for the most
   common distro kernels.

Clearly all this is a waste of developer time, CPU cycles, memory,
reliability and debugging time. All that time would be more efficiently
spent auditing and debugging existing code to reduce the attack surface,
and CPU cycles + memory would be better spent adding double checks to
most sensible functions' entry points and user data processing.

Regards,
Willy


  parent reply	other threads:[~2008-09-05 20:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04  2:51 [patch] Add basic sanity checks to the syscall execution patch Arjan van de Ven
2008-09-04 12:01 ` Andi Kleen
2008-09-04 12:34   ` Alan Cox
2008-09-04 13:06     ` Andi Kleen
2008-09-04 12:44   ` Arjan van de Ven
2008-09-05  9:43     ` pageexec
2008-09-05 10:14       ` Benjamin Herrenschmidt
2008-09-05 10:49         ` pageexec
2008-09-05 10:57           ` Benjamin Herrenschmidt
2008-09-05 11:42             ` Ingo Molnar
2008-09-05 12:00               ` pageexec
2008-09-05 15:42                 ` Ingo Molnar
2008-09-05 16:23                   ` pageexec
2008-09-05 16:52                     ` Ingo Molnar
2008-09-05 17:26                       ` Andi Kleen
2008-09-05 19:42                         ` pageexec
2008-09-05 20:48                           ` Andi Kleen
2008-09-05 19:37                       ` pageexec
2008-09-06 15:42                         ` Ingo Molnar
2008-09-07  0:17                           ` pageexec
2008-09-05 12:01               ` Andi Kleen
2008-09-05 20:41               ` Willy Tarreau [this message]
2008-09-06 15:45                 ` Ingo Molnar
2008-09-06 16:34                   ` Jeroen van Rijn
2008-09-07 12:53                   ` Pavel Machek
2008-09-05 16:05       ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080905204134.GI19337@1wt.eu \
    --to=w@1wt.eu \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pageexec@freemail.hu \
    --cc=tglx@tglx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox