public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Makan Pourzandi <Makan.Pourzandi@ericsson.com>
To: "Serge E. Hallyn" <hallyn@CS.WM.EDU>
Cc: 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, 09 Sep 2004 16:40:46 -0400	[thread overview]
Message-ID: <4140BFCE.8010701@ericsson.com> (raw)
In-Reply-To: <20040909190511.GB28807@escher.cs.wm.edu>



Serge E. Hallyn wrote:
> Quoting Chris Wright (chrisw@osdl.org):
> 
>>* Makan Pourzandi (Makan.Pourzandi@ericsson.com) wrote:
> 
> ...
> 
>>>We realized that when a shared library is opened by a binary it can 
>>>still be modified. To solve the problem, we block the write access to 
>>>the shared binary while it is loaded.
>>
>>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.

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.

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.


> to an ELF file can be prevented by mmap(PROT_EXEC).  Presumably, if

Regards,
Makan

> you are replacing an ELF file, you will always want to do 
> "mv foo.so foo.so.del; cp new/foo.so foo.so" anyway.
> 
> Thoughts?
> 
> thanks,
> -serge
> 

-- 

Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*


  reply	other threads:[~2004-09-09 20:50 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 [this message]
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=4140BFCE.8010701@ericsson.com \
    --to=makan.pourzandi@ericsson.com \
    --cc=axelle.apvrille@trusted-logic.fr \
    --cc=chrisw@osdl.org \
    --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