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.
prev 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®