[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1156439113.3007.170.camel@localhost.localdomain>
Date: Thu, 24 Aug 2006 18:05:13 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: "Serge E. Hallyn" <sergeh@...ibm.com>
Cc: kjhall@...ibm.com, Benjamin LaHaise <bcrl@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
LSM ML <linux-security-module@...r.kernel.org>,
David Safford <safford@...ibm.com>,
Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH 3/7] SLIM main patch
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists