Re: [PATCH 1/3] fs: add O_BENEATH flag to openat(2)

On Mon, Nov 3, 2014 at 9:37 AM, David Drysdale wrote: > On Mon, Nov 3, 2014 at 3:42 PM, Andy Lutomirski wrote: >> This is extremely useful in conjunction with seccomp. > > Yes, that was my understanding of how the Chrome[OS] folk wanted > to use it. Yes, exactly. Without this, if we want to give

Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook wrote: > On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski wrote: >> [cc: Eric Biederman] >> >> On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook wrote: >>> Julien had been wanting something like this too (though he'd suggested >>> it via prctl): limit the

Re: [PATCH v5 0/6] seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC

On Tue, Jun 3, 2014 at 3:12 AM, Michael Kerrisk wrote: > [Kees, thank you for CCing linux-api] > > On Tue, Jun 3, 2014 at 1:08 AM, Andy Lutomirski wrote: >> On Mon, Jun 2, 2014 at 4:05 PM, Kees Cook wrote: > >>> I'd like to hear from other folks on this (akpm?). My instinct is to >>> continue us

Re: [PATCH v2 0/9] procfs: protect /proc//* files with file->f_cred

On Wed, Oct 2, 2013 at 11:07 AM, Kees Cook wrote: > > On Wed, Oct 2, 2013 at 11:00 AM, Andy Lutomirski wrote: > > On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote: > >> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski > >> wrote: > >>> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote: > >>

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 5, 2013 at 3:08 PM, H. Peter Anvin wrote: > On 04/05/2013 03:06 PM, Julien Tinnes wrote: >> >> Speaking of IDT, and to capture some off-thread discussion here, we >> should remember that the "SGDT" and "SIDT" instructions aren't >>

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 5, 2013 at 12:11 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel >> can be randomized at boot. >> >> This makes kernel vulnerabilities harder to reliably exploit, especially >> from remote attacks and local p

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 5, 2013 at 7:49 AM, Borislav Petkov wrote: > On Thu, Apr 04, 2013 at 01:07:35PM -0700, Kees Cook wrote: >> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel >> can be randomized at boot. > > Right, > > if I'm reading this whole deal correctly, I have an issue wi

Re: [PATCH 3/3] x86: kernel base offset ASLR

Natural evolution: when the cluster is the computer, kernel panics are recoverable like segfaults in a multi-process OS. You have a point and 8 bits isn't perfect, but it's already useful regardless, in certain scenarios. On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote: > It seems to me tha

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:27 PM, H. Peter Anvin wrote: > On 04/04/2013 01:23 PM, Julien Tinnes wrote: >> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote: >>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote: >>>> On 04/04/2013 01:07 PM, Kees Cook wrote:

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote: > On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote: >> On 04/04/2013 01:07 PM, Kees Cook wrote: >>> However, the benefits of >>> this feature in certain environments exceed the perceived weaknesses[2]. >>

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote: > On 04/04/2013 01:07 PM, Kees Cook wrote: >> However, the benefits of >> this feature in certain environments exceed the perceived weaknesses[2]. > > Could you clarify? I think privilege reduction in general, and sandboxing in particular, can

Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)

't have anything preventing the attacker from bruteforcing...) to use existing code. [1]: Nergal, Advanced return into-lib(c) http://www.phrack.org/show.php?p=58&a=4 -- Julien TINNES - & france telecom - R&D Division/MAPS/NSS Research Engineer - Internet/Intranet Security GPG: C050 EF1A

Re: Patch 4/6 randomize the stack pointer

Horst von Brand wrote: Julien TINNES <[EMAIL PROTECTED]> said: Not very important but ((get_random_int() % 4096) << 4) could be optimized into get_random_int() & 0xFFF0. Check first if the compiler doesn't do it by itself. The compiler cannot guess that get_random_int()

Re: Patch 4/6 randomize the stack pointer

exploit find the correct address will raise). Of course you could inject code in other places or use existing code in address space (libc or running program) but this is at least a first layer of protection and adding layers is exactly what security is about. -- Julien TINNES - & france te

Re: Patch 4/6 randomize the stack pointer

Not very important but ((get_random_int() % 4096) << 4) could be optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2 you won't loose any entropy by doing & 0xFFF instead of %4096 Regards, -- Julien TINNES - & france telecom - R&D Division

Re: Patch 0/6 virtual address space randomisation

its in an additional PaX patch, it's no problem! It's more important to have a correct basis, focus on that. -- Julien TINNES - & france telecom - R&D Division/MAPS/NSS Research Engineer - Internet/Intranet Security GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6 - To un

Re: Patch 0/6 virtual address space randomisation

ayout? You miss a whole case here where legacy layout is used. -- Julien TINNES - & france telecom - R&D Division/MAPS/NSS Research Engineer - Internet/Intranet Security GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6 - To unsubscribe from this list: send the line "unsubscrib