mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ulrich Drepper" <drepper@gmail.com>
To: Nix <nix@esperi.org.uk>
Cc: "Arjan van de Ven" <arjan@infradead.org>,
	"Makan Pourzandi" <Makan.Pourzandi@ericsson.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	"Serue Hallyen" <serue@us.ibm.com>,
	"Axelle Apvrille" <axelle_apvrille@rc1.vip.ukl.yahoo.com>,
	"disec-devel@lists.sourceforge.net" 
	<disec-devel@lists.sourceforge.net>
Subject: Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries
Date: Fri, 28 Apr 2006 08:26:29 -0700	[thread overview]
Message-ID: <a36005b50604280826p2b2f8eabm72875eb825a4434@mail.gmail.com> (raw)
In-Reply-To: <87psj6pvqo.fsf@hades.wkstn.nix>

On 4/24/06, Nix <nix@esperi.org.uk> wrote:
> > But preventing every type of code loading or generation at userlevel
> > cannot be prevented this way.
>
> Oh, indeed not. It's just a stopgap that blocks some (large) percentage
> of script kiddy attacks that involve downloading binaries and then
> executing them, or even compiling them on the spot (not that those are
> as common these days).

Script kiddies don't write the exploit code themselves.  And for those
who write the code it is no problem to circumvent the signature
testing.


> Yeah. I'll admit I've found signed binaries principally useful on
> stripped-down firewalls and firewall UML instances. These boxes don't
> tend to run, say, CLISP or SBCL or OpenOffice (at least if they do the
> firewall maintainer needs shooting).

But they have Perl, Python, etc.  Those are sufficient.  Heck, I can
cause havor with bash.


> Combine it with SELinux, exec-shield, FORTIFY_SOURCE, -fstack-protector
> and, say, a COWed filesystem read off a CD and reset with every boot,
> and you start to get a bit less insecure than you would otherwise be.

Take signed binaries off of this list and you don't lose anything.


> It's another hurdle for the bad guys to leap, and many will fall at the
> wayside.

It is a little one-time effort.  This approach differs in that it
simply shifts the way binaries are introduced.  I can write a dynamic
loader in Perl.  and after that I don't load ELF binaries through the
kernel ever again.  If such a loader doesn't exist today it could very
well exist in a few months and after that this "protection" is
completely useless.  Every script kiddy will have it.

This is the big difference to techniques like randomization which
might be circumventent with a certain probability but never fully can
be removed.  Stacking those kind of protections is a good idea
because, if they are not fully correlated, the stacking provides
additional protection.  Signed binaries do not.

      parent reply	other threads:[~2006-04-28 15:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-21  9:56 Makan Pourzandi
2006-04-21 16:12 ` Stephen Smalley
2006-04-21 16:13   ` [Disec-devel] " Axelle Apvrille
2006-04-21 16:29     ` Stephen Smalley
2006-04-23 12:18 ` Arjan van de Ven
2006-04-23 16:38   ` Ulrich Drepper
2006-04-24 20:24     ` Nix
2006-04-25 20:30       ` Serge E. Hallyn
2006-04-28 15:26       ` Ulrich Drepper [this message]

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=a36005b50604280826p2b2f8eabm72875eb825a4434@mail.gmail.com \
    --to=drepper@gmail.com \
    --cc=Makan.Pourzandi@ericsson.com \
    --cc=arjan@infradead.org \
    --cc=axelle_apvrille@rc1.vip.ukl.yahoo.com \
    --cc=disec-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nix@esperi.org.uk \
    --cc=serue@us.ibm.com \
    /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

all inboxes | Powered by JetHome®