linux-kernel - Re: JIT emulator needs

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <787b0d920706202021t567b2fefu869a03ef76f245da@mail.gmail.com>
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/