mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ulrich Drepper" <drepper@gmail.com>
To: "Arjan van de Ven" <arjan@infradead.org>
Cc: "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: Sun, 23 Apr 2006 09:38:34 -0700	[thread overview]
Message-ID: <a36005b50604230938k2f52186ek477850b3e3a7192@mail.gmail.com> (raw)
In-Reply-To: <1145794712.3131.10.camel@laptopd505.fenrus.org>

On 4/23/06, Arjan van de Ven <arjan@infradead.org> wrote:
> does this also prevent people writing their own elf loader in a bit of
> perl and just mmap the code ?

You will never get 100% protection from a mechanism like signed
binaries.  What you can get in collaboration with other protections
like SELinux is another layer of security.  That's good IMO.  Not
being able to slide in modified and substituted binaries which then
would be marked to get certain privileges is a plus.

But preventing every type of code loading or generation at userlevel
cannot be prevented this way.  Just look at the code proposed to deal
with execmem problems in
http://people.redhat.com/drepper/selinux-mem.html.  This is with all
the SELinux mechanisms in place and activated.  You can prevent by
using the noexec mount option for every writable filesystem. But this
is so far not possible for ordinary machines.  There are widely used
programs out there which need to dynamically generate code.

Signed binaries are therefore a complete solution only for a very
limited number of situation.  For embedded systems I see this but here
we also have the "Tivo problem" where devices are built on top of
Linux and people are still prevented from extending/modifying them. 
Beside that there is potentially some locked down machines with
limited functionality which can use it (e.g., DMZ servers, but they
mustn't use Java etc).

So, I do not think that signed binaries have a big upside.  And they
have a potential big downside.  The better approach to ensure that
SELinux, for instance, doesn't change the labels for incorrect
binaries is to integrate restorecon etc with the package manager and
have functionality in the package manager to recognize incorrect
binaries.  This might again mean signed binaries although I imagine
the current signed hash values work fine, too.  Although we might want
to go from MD5 to SHA256.

I have been working on signed binaries at some point myself but
abandoned it after realizing that it realistically only can be
misused.  If I'd have a vote I'd keep this stuff out of the kernel.

  reply	other threads:[~2006-04-23 16:38 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 [this message]
2006-04-24 20:24     ` Nix
2006-04-25 20:30       ` Serge E. Hallyn
2006-04-28 15:26       ` Ulrich Drepper

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=a36005b50604230938k2f52186ek477850b3e3a7192@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=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®