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: "Serge E. Hallyn" <hallyn@CS.WM.EDU>,
	Chris Wright <chrisw@osdl.org>,
	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: Thu, 9 Sep 2004 14:03:49 -0700	[thread overview]
Message-ID: <20040909140349.C1924@build.pdx.osdl.net> (raw)
In-Reply-To: <4140BFCE.8010701@ericsson.com>; from Makan.Pourzandi@ericsson.com on Thu, Sep 09, 2004 at 04:40:46PM -0400

* 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.
> 
> I want to narrow down the discussion, I believe that some people could 
> get confused with the mention of "file" here. AFAICT, the above problem 
> only concerns the shared libraries. Digsig applies only to binaries: in 
> digsig_file_mmap() implementing the file_mmap LSM hook, if the file is 
> not executable there is a return and no verification or any other 
> blocking is done.

No, it's the mmap PROT check that's the issue.

> For executables, there is no meaning to load them on read mode, you 
> should have execute permission. if you then load them for execution 
> IMHO, it makes sense to block the writing on that file.

Thing is, x86 makes no distinction btween r/x so, have you tried mmaping
with read, then executing (I haven't)?  If it works, then you may find
that there are dumb things out there that do that as well (which you
wouldn't be able to protect, and become one attack vector).  You can make
a file read-only (no exec bits), and still execute it with ld.so.  Same
as bash can interpret readonly shell script files.  Now, ld.so _will_
mmap PROT_EXEC, so it works for you.

> For shared libraries, you're right. the problem exists, the shared 
> libraries can be loaded being only readable (even though I remember 
> reading in exec.c:sys_uselib() kernel 2.6.8.1 that the shared libraries 
> must be both readable and executable due to "security reasons", but I'm 
> not an expert and definitely readable is enough to load the shared 
> library but I'll be happy to learn more about this.)
> 
> > 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.

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

  reply	other threads:[~2004-09-09 21:05 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 [this message]
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=20040909140349.C1924@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