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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <787b0d920706201125g2368a4e1i2d115b0b2d5399e5@mail.gmail.com>
Date:	Wed, 20 Jun 2007 14:25:20 -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:
> 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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ