From: Chris Wright <chrisw@osdl.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Chris Wright <chrisw@osdl.org>,
Makan Pourzandi <Makan.Pourzandi@ericsson.com>,
linux-kernel@vger.kernel.org,
Axelle Apvrille <axelle.apvrille@trusted-logic.fr>,
david.gordon@ericsson.com, gaspoucho@yahoo.com
Subject: Re: [ANNOUNCE] Release Digsig 1.3.1: kernel module for run-time authentication of binaries
Date: Thu, 9 Sep 2004 10:42:56 -0700 [thread overview]
Message-ID: <20040909104256.T1924@build.pdx.osdl.net> (raw)
In-Reply-To: <20040909172301.GA28466@escher.cs.wm.edu>; from serue@us.ibm.com on Thu, Sep 09, 2004 at 01:23:01PM -0400
* Serge E. Hallyn (serue@us.ibm.com) wrote:
> > > - support to avoid vulnerability for rewrite of shared
> > > libraries
> >
> > Could you elaborate on this one?
>
> When a file is being executed, deny_write_access(file) is called to
> prevent writing until execution completes. Because deny_write_access
> is not exported from fs/namei.c, we emulate this behavior for shared
> libraries.
Hmm, ok, so you're relying on the loader to do PROT_EXEC mmaps for
shared libraries? Probably not required at least on x86. Also, does
this work when executing loader directly (/lib/ld.so /bin/ps), and with
dlopen?
> > > Future works
> > > =============
> > >
> > > - improving the caching and revocation: it is currently tested
> > > and will be sent out soon after stability testing
> >
> > Should be helpful enough to cache result until thing's opened for
> > writing, or is that what you're doing now?
>
> Exactly. When the file is opened for writing (which as much as possible
> requires the file to not be executed), we uncache the signature
> validation.
>
> (The new patch hashes revocations (they were on a linked list), and
> steals the seqlock-based structure Rik van Riel had suggested for
> the selinux avc cache for use in the signature revocation cache. There
> is no change in functionality, only (hopefully) performance improvements.)
Ok, I see. Makes sense.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
next prev parent reply other threads:[~2004-09-09 17:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 15:55 [ANNOUNCE] Release Digsig 1.3.1: kernel module for run-time authentication of binaries Makan Pourzandi
2004-09-09 16:24 ` Chris Wright
2004-09-09 17:23 ` Serge E. Hallyn
2004-09-09 17:42 ` Chris Wright [this message]
2004-09-09 18:43 ` Serge E. Hallyn
2004-09-09 17:31 ` Makan Pourzandi
2004-09-09 17:55 ` Chris Wright
2004-09-09 19:05 ` Serge E. Hallyn
2004-09-09 20:40 ` Makan Pourzandi
2004-09-09 21:03 ` Chris Wright
2004-09-09 21:45 ` Serge E. Hallyn
2004-09-10 21:28 ` Chris Wright
2004-09-10 20:53 ` Makan Pourzandi
2004-09-10 21:26 ` Chris Wright
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=20040909104256.T1924@build.pdx.osdl.net \
--to=chrisw@osdl.org \
--cc=Makan.Pourzandi@ericsson.com \
--cc=axelle.apvrille@trusted-logic.fr \
--cc=david.gordon@ericsson.com \
--cc=gaspoucho@yahoo.com \
--cc=linux-kernel@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