Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor

On Wed, Sep 23, 2020 at 08:00:07PM +0200, Solar Designer wrote: > A couple of other things Brad kindly pointed out: > > SELinux already has similar protections (execmem, execmod): > > http://lkml.iu.edu/hypermail/linux/kernel/0508.2/0194.html > https://danwalsh.livejou

Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor

On Wed, Sep 23, 2020 at 04:39:31PM +0200, Florian Weimer wrote: > * Solar Designer: > > > While I share my opinion here, I don't mean that to block Madhavan's > > work. I'd rather defer to people more knowledgeable in current userland > > and ABI issues/limitati

Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor

On Wed, Sep 23, 2020 at 05:18:35PM +0200, Pavel Machek wrote: > > It sure does make sense to combine ret2libc/ROP to mprotect() with one's > > own injected shellcode. Compared to doing everything from ROP, this is > > easier and more reliable across versions/builds if the desired > > payload > >

Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor

On Wed, Sep 23, 2020 at 11:14:56AM +0200, Solar Designer wrote: > On Wed, Sep 23, 2020 at 10:14:26AM +0200, Pavel Machek wrote: > > > Introduction > > > > > > > > > Dynamic code is used in many different user applications. Dynamic code is &g

Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor

On Wed, Sep 23, 2020 at 10:14:26AM +0200, Pavel Machek wrote: > > Introduction > > > > > > Dynamic code is used in many different user applications. Dynamic code is > > often generated at runtime. Dynamic code can also just be a pre-defined > > sequence of machine instructions in a

Re: [PATCH v2] Documentation/security-bugs: provide more information about linux-distros

rstand those policies as they differ from > > > > secur...@kernel.org's policy. > > > > > > > > Suggested-by: Solar Designer > > > > Signed-off-by: Sasha Levin > > > > > > Sorry, but NACK, see below... I like Sasha's PATCH v2 better, but if Kees insists

Re: [PATCH 1/3] x86/asm: Pin sensitive CR0 bits

On Tue, Feb 26, 2019 at 03:36:45PM -0800, Kees Cook wrote: > static inline void native_write_cr0(unsigned long val) > { > - asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order)); > + bool warn = false; > + > +again: > + val |= X86_CR0_WP; > + /* > + * In order to

Re: [PATCH v2] x86/asm: Pin sensitive CR4 bits

On Wed, Feb 20, 2019 at 01:20:58PM -0800, Kees Cook wrote: > On Wed, Feb 20, 2019 at 10:49 AM Solar Designer wrote: > > > > On Wed, Feb 20, 2019 at 10:09:34AM -0800, Kees Cook wrote: > > > + if (WARN_ONCE((val & cr4_pin) != cr4_pin, "cr4 bypass attempt?!\n&

Re: [PATCH v2] x86/asm: Pin sensitive CR4 bits

On Wed, Feb 20, 2019 at 10:09:34AM -0800, Kees Cook wrote: > +extern volatile unsigned long cr4_pin; > + > static inline void native_write_cr4(unsigned long val) > { > +again: > + val |= cr4_pin; > asm volatile("mov %0,%%cr4": : "r" (val), "m" (__force_order)); > + /* > + * If

Re: [kernel-hardening] [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Tue, Dec 05, 2017 at 11:21:00AM +0100, Salvatore Mesoraca wrote: > 2017-11-30 17:30 GMT+01:00 Solar Designer <so...@openwall.com>: > > $ strace flock /tmp/lockfile -c cat > > [...] > > open("/tmp/lockfile", O_RDONLY|O_CREAT|O_NOCTTY, 0666) = 3 > >

Re: [kernel-hardening] [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Tue, Dec 05, 2017 at 11:21:00AM +0100, Salvatore Mesoraca wrote: > 2017-11-30 17:30 GMT+01:00 Solar Designer : > > $ strace flock /tmp/lockfile -c cat > > [...] > > open("/tmp/lockfile", O_RDONLY|O_CREAT|O_NOCTTY, 0666) = 3 > > flock(3, LOCK_EX)

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Thu, Nov 30, 2017 at 04:53:06PM +, David Laight wrote: > From: Salvatore Mesoraca > > if a program tries to open a file, in a sticky directory, > > with the O_CREAT flag and without the O_EXCL, it probably has a bug. > > This feature allows to detect and potentially block programs that > >

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Thu, Nov 30, 2017 at 04:53:06PM +, David Laight wrote: > From: Salvatore Mesoraca > > if a program tries to open a file, in a sticky directory, > > with the O_CREAT flag and without the O_EXCL, it probably has a bug. > > This feature allows to detect and potentially block programs that > >

Re: [kernel-hardening] [PATCH v3 2/2] Protected O_CREAT open in sticky directories

Replying to Salvatore and Ian at once, and CC'ing H. Peter Anvin and Karel Zak for util-linux flock(1). On Thu, Nov 30, 2017 at 02:57:06PM +, Ian Campbell wrote: > On Thu, 2017-11-30 at 15:39 +0100, Salvatore Mesoraca wrote: > > 2017-11-27 1:26 GMT+01:00 Solar Designer <so...@

Re: [kernel-hardening] [PATCH v3 2/2] Protected O_CREAT open in sticky directories

Replying to Salvatore and Ian at once, and CC'ing H. Peter Anvin and Karel Zak for util-linux flock(1). On Thu, Nov 30, 2017 at 02:57:06PM +, Ian Campbell wrote: > On Thu, 2017-11-30 at 15:39 +0100, Salvatore Mesoraca wrote: > > 2017-11-27 1:26 GMT+01:00 Solar Designer : > &

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Fri, Nov 24, 2017 at 12:43:47PM +0100, Salvatore Mesoraca wrote: > 2017-11-24 11:53 GMT+01:00 David Laight : > > From: Alan Cox > >> Sent: 22 November 2017 16:52 > >> > >> On Wed, 22 Nov 2017 09:01:46 +0100 Salvatore Mesoraca > >> wrote: > >> >

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Fri, Nov 24, 2017 at 12:43:47PM +0100, Salvatore Mesoraca wrote: > 2017-11-24 11:53 GMT+01:00 David Laight : > > From: Alan Cox > >> Sent: 22 November 2017 16:52 > >> > >> On Wed, 22 Nov 2017 09:01:46 +0100 Salvatore Mesoraca > >> wrote: > >> > >> > Disallows O_CREAT open missing the O_EXCL

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

On Wed, Sep 20, 2017 at 01:18:04PM +0200, Yann Droneaud wrote: > Le mardi 19 septembre 2017 ?? 19:16 +0200, Solar Designer a ??crit : > > > > We could put/require a NUL in the middle of the canary, > > but with the full canary being only 64-bit at most that would also > &g

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

On Wed, Sep 20, 2017 at 01:18:04PM +0200, Yann Droneaud wrote: > Le mardi 19 septembre 2017 ?? 19:16 +0200, Solar Designer a ??crit : > > > > We could put/require a NUL in the middle of the canary, > > but with the full canary being only 64-bit at most that would also > &g

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

On Wed, May 24, 2017 at 11:57:46AM -0400, r...@redhat.com wrote: > Zero out the first byte of the stack canary value on 64 bit systems, > in order to mitigate unterminated C string overflows. > > The null byte both prevents C string functions from reading the > canary, and from writing it if the

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

On Wed, May 24, 2017 at 11:57:46AM -0400, r...@redhat.com wrote: > Zero out the first byte of the stack canary value on 64 bit systems, > in order to mitigate unterminated C string overflows. > > The null byte both prevents C string functions from reading the > canary, and from writing it if the

Re: [RFC] Restrict writes into untrusted FIFOs and regular files

On Tue, Sep 19, 2017 at 06:06:15PM +0200, Salvatore Mesoraca wrote: > 2017-09-19 2:37 GMT+02:00 Solar Designer <so...@openwall.com>: > > On Mon, Sep 18, 2017 at 02:00:50PM -0700, Kees Cook wrote: > >> On Fri, Sep 15, 2017 at 1:43 AM, Salvatore Mesoraca > >&g

Re: [RFC] Restrict writes into untrusted FIFOs and regular files

On Tue, Sep 19, 2017 at 06:06:15PM +0200, Salvatore Mesoraca wrote: > 2017-09-19 2:37 GMT+02:00 Solar Designer : > > On Mon, Sep 18, 2017 at 02:00:50PM -0700, Kees Cook wrote: > >> On Fri, Sep 15, 2017 at 1:43 AM, Salvatore Mesoraca > >> wrote: >

Re: [RFC] Restrict writes into untrusted FIFOs and regular files

On Mon, Sep 18, 2017 at 02:00:50PM -0700, Kees Cook wrote: > On Fri, Sep 15, 2017 at 1:43 AM, Salvatore Mesoraca > wrote: > > The purpose is to make data spoofing attacks harder. > > Do you have any examples of attacks (CVEs, blog posts, etc) that you > could link to in

Re: [RFC] Restrict writes into untrusted FIFOs and regular files

On Mon, Sep 18, 2017 at 02:00:50PM -0700, Kees Cook wrote: > On Fri, Sep 15, 2017 at 1:43 AM, Salvatore Mesoraca > wrote: > > The purpose is to make data spoofing attacks harder. > > Do you have any examples of attacks (CVEs, blog posts, etc) that you > could link to in this commit? I doubt

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

Hi all, On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote: > This issue occurs post stackguard patches correct? Fixing it sounds like > this might go beyond hardening and into CVE territory. Since this thread is public on LKML, as it should be, it's no longer valid to be CC'ed

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

Hi all, On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote: > This issue occurs post stackguard patches correct? Fixing it sounds like > this might go beyond hardening and into CVE territory. Since this thread is public on LKML, as it should be, it's no longer valid to be CC'ed

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer <so...@openwall.com> > >>> wrote: > >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > >>> >> *) When modules_autoload_mode is set to (2), automatic

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer > >>> wrote: > >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > >>> >> *) When modules_autoload_mode is set to (2), automatic module loading > &

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: > On Mon, May 22, 2017 at 2:08 PM, Solar Designer <so...@openwall.com> wrote: > > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > >> *) When modules_autoload_mode is set to (2),

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: > On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote: > > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > >> *) When modules_autoload_mode is set to (2), automatic module loading is > >

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Djalal, Thank you for your work on this! On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > *) When modules_autoload_mode is set to (2), automatic module loading is > disabled for all. Once set, this value can not be changed. What purpose does this securelevel-like property

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Djalal, Thank you for your work on this! On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: > *) When modules_autoload_mode is set to (2), automatic module loading is > disabled for all. Once set, this value can not be changed. What purpose does this securelevel-like property

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

On Fri, Mar 24, 2017 at 03:21:06PM -0700, Eric Dumazet wrote: > Looks easy enough to fix ? Oh. Probably. Thanks. Need to test, but I guess you already did? > diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c > index >

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

On Fri, Mar 24, 2017 at 03:21:06PM -0700, Eric Dumazet wrote: > Looks easy enough to fix ? Oh. Probably. Thanks. Need to test, but I guess you already did? > diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c > index >

non-response to IPI kills wrong(?) task, confuses logs

Hi, Adam Zabrocki, CC'ed here, informed me of the following: There is an undesirable situation in SMP Linux machines when sending an IPI via the smp_call_function_single() API: /* * smp_call_function_single - Run a function on a specific CPU * @func: The function to run. This must be fast and

non-response to IPI kills wrong(?) task, confuses logs

Hi, Adam Zabrocki, CC'ed here, informed me of the following: There is an undesirable situation in SMP Linux machines when sending an IPI via the smp_call_function_single() API: /* * smp_call_function_single - Run a function on a specific CPU * @func: The function to run. This must be fast and

Re: [patch] lib: check for strcpy() overflows to fixed length buffers

On Wed, Apr 30, 2014 at 06:08:44PM +0300, Dan Carpenter wrote: > There are sometimes where we know that we are doing an strcpy() into a > fixed length buffer. In those cases, we could verify that the strcpy() > doesn't overflow. This patch introduces DEBUG_STRICT_SLOW_STRCPY_CHECKS > if you want

Re: [patch] lib: check for strcpy() overflows to fixed length buffers

On Wed, Apr 30, 2014 at 06:08:44PM +0300, Dan Carpenter wrote: There are sometimes where we know that we are doing an strcpy() into a fixed length buffer. In those cases, we could verify that the strcpy() doesn't overflow. This patch introduces DEBUG_STRICT_SLOW_STRCPY_CHECKS if you want to