From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kylene Jo Hall <kjhall@us.ibm.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
LSM ML <linux-security-module@vger.kernel.org>,
Dave Safford <safford@us.ibm.com>, Mimi Zohar <zohar@us.ibm.com>,
Serge Hallyn <sergeh@us.ibm.com>
Subject: Re: [PATCH 3/7] SLIM main patch
Date: Thu, 24 Aug 2006 12:26:55 +0100 [thread overview]
Message-ID: <1156418815.3007.89.camel@localhost.localdomain> (raw)
In-Reply-To: <1156365357.6720.87.camel@localhost.localdomain>
Ar Mer, 2006-08-23 am 13:35 -0700, ysgrifennodd Kylene Jo Hall:
> Example: The current process is running at the USER level and writing to
> a USER file in /home/user/. The process then attempts to read an
> UNTRUSTED file. The current process will become UNTRUSTED and the read
> allowed to proceed but first write access to all USER files is revoked
> including the ones it has open.
Which really doesn't mean anything in many cases because there are many
ways to get data out of a file handle once you had it opened for write
including sharing via non file handle paths.
You also have to deal with existing mmap() mappings and outstanding I/O.
So here are some ways to break it
SysV shared memory
mmap
or just race it:
Open the USER file
create a new thread
thread #1 create a pipe to a new process ("receiver")
thread #1 fill pipe
thread #1 issue write of buffer that will hold secret data
[blocks after check for rights]
thread #2
wait for thread #1 to block
read secret data into buffer
send signal to "receiver"
receiver now empties the pipe, the write completes and I get the
goodies.
This is why you need a proper implementation of revoke(2) in Linux. You
can't really do it any more easily.
next prev parent reply other threads:[~2006-08-24 11:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-23 19:05 [PATCH 3/7] SLIM main patch Kylene Jo Hall
2006-08-23 19:27 ` Benjamin LaHaise
2006-08-23 20:35 ` Kylene Jo Hall
2006-08-23 20:41 ` Benjamin LaHaise
2006-08-23 22:20 ` Kylene Jo Hall
2006-08-24 8:31 ` Arjan van de Ven
2006-08-24 11:26 ` Alan Cox [this message]
2006-08-24 13:32 ` Serge E. Hallyn
2006-08-24 13:37 ` Benjamin LaHaise
2006-08-24 13:58 ` Serge E. Hallyn
2006-08-24 14:00 ` Benjamin LaHaise
2006-08-24 14:16 ` Serge E. Hallyn
2006-08-24 14:15 ` Alan Cox
2006-08-24 15:23 ` Serge E. Hallyn
2006-08-24 17:05 ` Alan Cox
2006-08-24 17:34 ` David Safford
2006-08-24 19:16 ` Serge E. Hallyn
2006-08-24 20:21 ` David Safford
2006-08-24 20:41 ` Mimi Zohar
2006-08-24 22:13 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2006-09-12 17:57 Kylene Jo Hall
2006-09-14 23:52 ` Andrew Morton
2006-09-15 16:57 ` Kylene Jo Hall
2006-09-26 18:44 ` Stephen Smalley
2006-10-19 20:48 ` Kylene Jo Hall
2006-10-20 15:32 ` Stephen Smalley
2006-10-20 17:58 ` Stephen Smalley
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=1156418815.3007.89.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@kvack.org \
--cc=kjhall@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=safford@us.ibm.com \
--cc=sergeh@us.ibm.com \
--cc=zohar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.