On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
>>> c. open() flag to unlink a file before returning the fd
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
>> You probably want a tmpfile(3) -like affair which never has a
>> pathname to begin with. It could be useful
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful for
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful for
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > and these methods also destroy yourself on any machine with a looser
> > > > cache coherency between I and D-cache
> > > >
> > > > for all but x86 you pretty much have to do the mprotect() between the
> > > > two states to deal
> > > > and these methods also destroy yourself on any machine with a looser
> > > > cache coherency between I and D-cache
> > > >
> > > > for all but x86 you pretty much have to do the mprotect() between the
> > > > two states to deal with the cache flushing properly...
> > >
> > > If the
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
> On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> > > Right now, Linux isn't all that friendly to JIT emulators.
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
> On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> > > Right now, Linux isn't all that friendly to JIT emulators.
> > > Here are the problems and suggestions to improve
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
On 6/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the
and these methods also destroy yourself on any machine with a looser
cache coherency between I and D-cache
for all but x86 you pretty much have to do the mprotect() between the
two states to deal with the cache flushing properly...
If the instructions to force data
On 6/22/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
On 6/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here
On 6/22/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
and these methods also destroy yourself on any machine with a looser
cache coherency between I and D-cache
for all but x86 you pretty much have to do the mprotect() between the
two states to deal with the cache
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful for
On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
>
> There is an SE Linux execmem restriction that
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
>
> There is an SE Linux execmem restriction that enforces W^X.
> Assuming you don't wish to just disable SE
Albert Cahalan <[EMAIL PROTECTED]> wrote:
> On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
>>> Right now, Linux isn't all that friendly to JIT emulators.
>>> Here are the problems and suggestions to improve the
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
> 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
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Albert Cahalan wrote:
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
Albert Cahalan [EMAIL PROTECTED] wrote:
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux,
On 6/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces
Albert Cahalan wrote:
>>
>> 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.
>
That's not what you're
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> 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
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
On 6/20/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
If the policy forbidding self-modifying code lacks a method of
exempting programs such as JIT interpreters (which I doubt) then
it's a problem. I'm with Alan on this one.
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> 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
William Lee Irwin III 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
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
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
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> If the policy forbidding self-modifying code lacks a method of
>> exempting programs such as JIT interpreters (which I doubt) then
>> it's a problem. I'm with Alan on this one.
On Tue, Jun 19, 2007 at 11:16:29PM -0400, Albert Cahalan
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
If the policy forbidding self-modifying code lacks a method of
exempting programs such as JIT interpreters (which I doubt) then
it's a problem. I'm with Alan on this one.
On Tue, Jun 19, 2007 at 11:16:29PM -0400, Albert Cahalan 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
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
William Lee Irwin III 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
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] 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
On 6/20/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
If the policy forbidding self-modifying code lacks a method of
exempting programs such as JIT interpreters (which I doubt) then
it's a problem. I'm with Alan on this one.
On
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
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] 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
Albert Cahalan wrote:
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.
That's not what you're trying to
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
> There is an SE Linux execmem restriction that enforces W^X.
> Assuming you don't wish to just disable SE
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that
Albert Cahalan wrote:
> There is an SE Linux execmem restriction that enforces W^X.
> Assuming you don't wish to just disable SE Linux, there are
> two ugly ways around the problem.
This should be fixed in SELinux, or more accurately the SELinux profile.
There is absolutely no other sane option.
Albert Cahalan wrote:
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the problem.
This should be fixed in SELinux, or more accurately the SELinux profile.
There is absolutely no other sane option.
On 6/8/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
On 6/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Albert Cahalan a écrit :
> Additions to better support JIT emulators:
>
> a. sysctl to set IPC_RMID by default
Not very good, this will break some apps.
As a sysctl, the admin gets to choose between
compatibility and sanity.
I can see
On Fri, 2007-06-08 at 12:10 +0100, Alan Cox wrote:
> > e. mremap() flag to get a read/write mapping of a read/exec one
> > f. mremap() flag to get a read/exec mapping of a read/write one
> > g. mremap() flag to make the 5th arg (new addr) be the upper limit
>
> This is all mprotect and munmap.
I
> There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
> Sometimes it is very helpful to have the
Albert Cahalan a écrit :
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the
Albert Cahalan a écrit :
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the
There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
Sometimes it is very helpful to have the
On Fri, 2007-06-08 at 12:10 +0100, Alan Cox wrote:
e. mremap() flag to get a read/write mapping of a read/exec one
f. mremap() flag to get a read/exec mapping of a read/write one
g. mremap() flag to make the 5th arg (new addr) be the upper limit
This is all mprotect and munmap.
I think
On 6/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Albert Cahalan a écrit :
Additions to better support JIT emulators:
a. sysctl to set IPC_RMID by default
Not very good, this will break some apps.
As a sysctl, the admin gets to choose between
compatibility and sanity.
I can see such a
On 6/8/07, Alan Cox [EMAIL PROTECTED] wrote:
There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
A
54 matches
Mail list logo
