From: Makan Pourzandi <Makan.Pourzandi@ericsson.com>
To: Chris Wright <chrisw@osdl.org>
Cc: "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 16:53:07 -0400 [thread overview]
Message-ID: <41421433.8090804@ericsson.com> (raw)
In-Reply-To: <20040909140349.C1924@build.pdx.osdl.net>
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.
regards,
Makan
>
> thanks,
> -chris
--
Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*
next prev parent reply other threads:[~2004-09-10 21:02 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 [this message]
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=41421433.8090804@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