public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: Makan Pourzandi <Makan.Pourzandi@ericsson.com>
Cc: Chris Wright <chrisw@osdl.org>,
	"Serge E. Hallyn" <hallyn@CS.WM.EDU>,
	linux-kernel@vger.kernel.org,
	Axelle Apvrille <axelle.apvrille@trusted-logic.fr>,
	serue@us.ibm.com, david.gordon@ericsson.com, gaspoucho@yahoo.com
Subject: Re: [ANNOUNCE] Release Digsig 1.3.1: kernel module for run-time authentication of binaries
Date: Fri, 10 Sep 2004 14:26:53 -0700	[thread overview]
Message-ID: <20040910142653.P1924@build.pdx.osdl.net> (raw)
In-Reply-To: <41421433.8090804@ericsson.com>; from Makan.Pourzandi@ericsson.com on Fri, Sep 10, 2004 at 04:53:07PM -0400

* Makan Pourzandi (Makan.Pourzandi@ericsson.com) wrote:
> Hi all,
> 
> see below:
> 
> Chris Wright wrote:
> > * Makan Pourzandi (Makan.Pourzandi@ericsson.com) wrote:
> > 
> >>Serge E. Hallyn wrote:
> >>
> >>>Quoting Chris Wright (chrisw@osdl.org):
> >>>
> >>>>AFAICT, this means anybody with read access to a file can block all
> >>>>writes.  This doesn't sound great.
> >>>
> >>>True.
> >>
> >>>This could be fixed by adding a check at the top of dsi_file_mmap for
> >>>file->f_dentry->d_inode->i_mode & MAY_EXEC.  Of course then shared
> >>>libraries which are installed without execute permissions will cause
> >>>apps to break.  On my quick test, I couldn't run xterm or vi  :)
> >>>
> >>>Note that blocking writes requires that the file be a valid ELF file,
> >>>as this is all that digsig mediates.  So I'm not sure which we worry
> >>>about more - the fact that all shared libraries have to be installed
> >>>with execute permissions (under the proposed solution), or that write
> >>
> >>
> >>My 2 cents, a quick browsing on my machine (fedora core 1) shows that 
> >>almost all my shared libraries are installed with both execution and 
> >>read permissions.  IMHO, I don't believe then that this should be 
> >>considered as a major issue.
> > 
> > 
> > This has nothing to do with file permissions aside of read.  All you need
> > is read permission, then you can mmap(PROT_EXEC) which will kick off the
> > check, and do deny_write_access.  It's a freeform way to lock writers
> > out of any readable file in the system.  This is why MAP_EXECUTABLE and
> > MAP_DENYWRITE are masked off at syscall entry.
> 
> Chris, my understanding is that Serge's patch even though it restricts a 
> little the system admin, is the best solution we have for time being. Am 
> I right?
> If this is the case I'll include Serge's patch in the cvs source code 
> and send out a new release soon.

The key piece I had missed is that it only checks elf files (I now see
read_elf_header).  So, the test may even be superfluous.  But try it,
see what breaks, then send fixes upstream ;-)  BTW, the read_elf_header
returns NULL on error, but IS_ERR is used against the returned pointer
(so errors will oops).  Also, the security_set_operations +
set_digsig_ops looks like it should be replaced with static structure
member assignment.  The digsig_sem can be statically setup with
DECLARE_MUTEX().  digsig.c::secondary should be static.
digsig.c::digsig_num_cached_sigs should be static and declared in
digsig_cache.c.  I'll keep digging.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

      reply	other threads:[~2004-09-10 21:30 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
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 [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=20040910142653.P1924@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=hallyn@CS.WM.EDU \
    --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