From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Serge E. Hallyn" <sergeh@us.ibm.com>
Cc: kjhall@us.ibm.com, Benjamin LaHaise <bcrl@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
LSM ML <linux-security-module@vger.kernel.org>,
David Safford <safford@us.ibm.com>, Mimi Zohar <zohar@us.ibm.com>
Subject: Re: [PATCH 3/7] SLIM main patch
Date: Thu, 24 Aug 2006 18:05:13 +0100 [thread overview]
Message-ID: <1156439113.3007.170.camel@localhost.localdomain> (raw)
In-Reply-To: <20060824152322.GD32764@sergelap.austin.ibm.com>
Ar Iau, 2006-08-24 am 10:23 -0500, ysgrifennodd Serge E. Hallyn:
> Or will the page associated with the tty already have the data, and this
> really just needs to be fixed in the tty itself?
It is a matter of the timing and the device. You need to do revocation
at the device level because your security state change must occur after
the devices have all been dealt with. This is why I said you need the
core of revoke() to do this.
Patches like the one below are really trying to wallpaper over the
cracks in an implementation that doesn't work. The moment you replace
that part of the implementation with a proper revocation method that
waits for resources to be safe then it all works.
The security model is fine, the implementation is hitting the same
revocation feature wall as others.
> permission from a vma_area_struct. This can be used, for example,
> by security modules wishing to revoke write permissions to a process
> whose clearance has changed.
What about drivers that use get_user_pages() - they have a locked kernel
mapping to the object but may not yet have accessed the data.
Plus the idea of a security indirect call every time we make a page
writable does not make me happy when considering performance. Not one
iota.
Alan
next prev parent reply other threads:[~2006-08-24 16:43 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
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 [this message]
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=1156439113.3007.170.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox