| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Jun 2007 23:21:49 -0400 From: "Albert Cahalan" <acahalan@...il.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: "William Lee Irwin III" <wli@...omorphy.com>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: JIT emulator needs On 6/20/07, H. Peter Anvin <hpa@...or.com> wrote: > Albert Cahalan wrote: > > 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. > > That's fine. That's a policy decision. That's what a security policy > *is*. The owner of the system has decided, by security policy, that > that is not allowed. Bypassing that is not acceptable. Fixing a bug should be acceptable. Look, let's back up a bit here. At a high level, what exactly do you imagine that this behavior was intended for? I suggest you list some examples of the attacks that are blocked. Can you come up with a reasonable argument that the current behavior is the least painful restriction required to block those attacks? Does the current behavior block any attack that the proposed behavior would not? (list the attacks please) - 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