Messages in this thread | | | Date | Wed, 20 Jun 2007 14:25:20 -0400 | From | "Albert Cahalan" <> | Subject | Re: JIT emulator needs |
| |
On 6/20/07, H. Peter Anvin <hpa@zytor.com> wrote: > William Lee Irwin III wrote:
> > I presumed an ELF note or extended filesystem attributes were already > > in place for this sort of affair. It may be that the model implemented > > is so restrictive that users are forbidden to create new executables, > > in which case using a different model is certainly in order. Otherwise > > the ELF note or attributes need to be implemented. > > Another thing to keep in mind, since we're talking about security > policies in the first place, is that anything like this *MUST* be > "opt-in" on the part of the security policy, because what we're talking > about is circumventing an explicit security policy just based on a > user-provided binary saying, in effect, "don't worry, I know what I'm > doing." > > Changing the meaning of an established explicit security policy is not > acceptable.
Not in this case. If an attacker can CHANGE THE BINARY then it's already game over.
Putting this into the security policy was an error born of lazyness to begin with. Abuse of the security mechanism was easier than hacking the toolchain, ELF loader, etc.
Either a binary needs self-modification, or it doesn't. This is determined by the author of the code. If you don't trust an executable that needs this ability, then you simply can not run it in a useful way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |