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 fo
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 secu
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 ins
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 the
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 enforce
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
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 situat
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 reaso
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 tr
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,
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 t
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.
O
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 executa
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 cas
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 certai
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 certain
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:
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 L
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 such
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 read/wr
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 pro
27 matches
Mail list logo
