On Tue, 2 Oct 2012, Andrew Morton wrote:
> On Tue, 2 Oct 2012 15:10:56 -0700
> Kees Cook wrote:
>
> > >> Has there been any more progress on this patch over-all?
> > >
> > > No progress.
> >
> > Al, Andrew, anyone? Thoughts on this?
> > (First email is https://lkml.org/lkml/2012/8/14/448)
>
>
On Tue, 2 Oct 2012 15:10:56 -0700
Kees Cook wrote:
> >> Has there been any more progress on this patch over-all?
> >
> > No progress.
>
> Al, Andrew, anyone? Thoughts on this?
> (First email is https://lkml.org/lkml/2012/8/14/448)
Wasn't cc'ed, missed it.
The patch looks straightforward
On Tue, Oct 2, 2012 at 2:41 PM, Ard Biesheuvel wrote:
> 2012/10/2 Kees Cook :
>>> If desired, additional restrictions can be imposed by using the
>>> security framework, e.g,, disallow non-final r-x mappings.
>>
>> Interesting; what kind of interface did you have in mind?
>
> The 'interface' we
2012/10/2 Kees Cook :
>> If desired, additional restrictions can be imposed by using the
>> security framework, e.g,, disallow non-final r-x mappings.
>
> Interesting; what kind of interface did you have in mind?
>
The 'interface' we use is a LSM .ko which registers handlers for
mmap() and
Hi,
On Mon, Aug 20, 2012 at 2:48 PM, Ard Biesheuvel
wrote:
>> This seems like a good idea to me. It would allow more than just the
>> loader to harden userspace allocations. It's a more direct version of
>> PaX's "MPROTECT" feature[1]. That feature hardens existing loaders,
>> but doesn't play
Hi,
On Mon, Aug 20, 2012 at 2:48 PM, Ard Biesheuvel
ard.biesheu...@gmail.com wrote:
This seems like a good idea to me. It would allow more than just the
loader to harden userspace allocations. It's a more direct version of
PaX's MPROTECT feature[1]. That feature hardens existing loaders,
but
2012/10/2 Kees Cook keesc...@chromium.org:
If desired, additional restrictions can be imposed by using the
security framework, e.g,, disallow non-final r-x mappings.
Interesting; what kind of interface did you have in mind?
The 'interface' we use is a LSM .ko which registers handlers for
On Tue, Oct 2, 2012 at 2:41 PM, Ard Biesheuvel ard.biesheu...@gmail.com wrote:
2012/10/2 Kees Cook keesc...@chromium.org:
If desired, additional restrictions can be imposed by using the
security framework, e.g,, disallow non-final r-x mappings.
Interesting; what kind of interface did you have
On Tue, 2 Oct 2012 15:10:56 -0700
Kees Cook keesc...@chromium.org wrote:
Has there been any more progress on this patch over-all?
No progress.
Al, Andrew, anyone? Thoughts on this?
(First email is https://lkml.org/lkml/2012/8/14/448)
Wasn't cc'ed, missed it.
The patch looks
On Tue, 2 Oct 2012, Andrew Morton wrote:
On Tue, 2 Oct 2012 15:10:56 -0700
Kees Cook keesc...@chromium.org wrote:
Has there been any more progress on this patch over-all?
No progress.
Al, Andrew, anyone? Thoughts on this?
(First email is https://lkml.org/lkml/2012/8/14/448)
> This seems like a good idea to me. It would allow more than just the
> loader to harden userspace allocations. It's a more direct version of
> PaX's "MPROTECT" feature[1]. That feature hardens existing loaders,
> but doesn't play nice with JITs (like Java), but this lets a loader
> (or JIT)
Hi,
On Tue, Aug 14, 2012 at 09:11:11PM +0200, Ard Biesheuvel wrote:
> This patch adds support for the PROT_FINAL flag to
> the mmap() and mprotect() syscalls.
>
> The PROT_FINAL flag indicates that the requested set
> of protection bits should be final, i.e., it shall
> not be allowed for a
Hi,
On Tue, Aug 14, 2012 at 09:11:11PM +0200, Ard Biesheuvel wrote:
This patch adds support for the PROT_FINAL flag to
the mmap() and mprotect() syscalls.
The PROT_FINAL flag indicates that the requested set
of protection bits should be final, i.e., it shall
not be allowed for a subsequent
This seems like a good idea to me. It would allow more than just the
loader to harden userspace allocations. It's a more direct version of
PaX's MPROTECT feature[1]. That feature hardens existing loaders,
but doesn't play nice with JITs (like Java), but this lets a loader
(or JIT) opt-in to
14 matches
Mail list logo
