From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751829AbdFMHlc (ORCPT ); Tue, 13 Jun 2017 03:41:32 -0400 Received: from mail-ua0-f196.google.com ([209.85.217.196]:33553 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdFMHla (ORCPT ); Tue, 13 Jun 2017 03:41:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <1497286620-15027-1-git-send-email-s.mesoraca16@gmail.com> <1497286620-15027-9-git-send-email-s.mesoraca16@gmail.com> From: Salvatore Mesoraca Date: Tue, 13 Jun 2017 09:41:29 +0200 Message-ID: Subject: Re: [PATCH 08/11] Creation of "pagefault_handler_x86" LSM hook To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com, Brad Spengler , PaX Team , Casey Schaufler , Kees Cook , James Morris , "Serge E. Hallyn" , x86@kernel.org, Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-06-12 19:32 GMT+02:00 Thomas Gleixner : > That explains, what you could do with it, but it completely lacks any > rationale WHY this is desired and good behaviour and how that is a security > feature. You are right, I could have been more descriptive. This is not a security feature "per se", it's a way to soften some unwanted side-effects of restrictive security features. In particular I'm trying to introduce a feature that will prevent the runtime creation of executable code in user-space programs: it's something like the PaX's MPROTECT feature. This hook is used to implement what PaX call "trampoline emulation" that, in practice, allow for some specific code sequences to be executed even if they are in non executable memory. This may look like a bad thing at first, but you have to consider that: - This allows for "memory restriction" features to stay on even when they should be turned off. And, even if this emulation makes the feature less effective, it's still better than having it turned off completely - The only code sequences emulated are trampolines used to make function calls. In many cases, when you have the chance to make arbitrary memory writes, you can already manipulate the control flow of the program by overwriting function pointers or return values. So, in many cases, the "trampoline emulation" doesn't introduce new exploit vectors. - It's a feature that can be turned on only if needed, on a per executable file basis. Thank your for taking the time to review this. From mboxrd@z Thu Jan 1 00:00:00 1970 From: s.mesoraca16@gmail.com (Salvatore Mesoraca) Date: Tue, 13 Jun 2017 09:41:29 +0200 Subject: [PATCH 08/11] Creation of "pagefault_handler_x86" LSM hook In-Reply-To: References: <1497286620-15027-1-git-send-email-s.mesoraca16@gmail.com> <1497286620-15027-9-git-send-email-s.mesoraca16@gmail.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 2017-06-12 19:32 GMT+02:00 Thomas Gleixner : > That explains, what you could do with it, but it completely lacks any > rationale WHY this is desired and good behaviour and how that is a security > feature. You are right, I could have been more descriptive. This is not a security feature "per se", it's a way to soften some unwanted side-effects of restrictive security features. In particular I'm trying to introduce a feature that will prevent the runtime creation of executable code in user-space programs: it's something like the PaX's MPROTECT feature. This hook is used to implement what PaX call "trampoline emulation" that, in practice, allow for some specific code sequences to be executed even if they are in non executable memory. This may look like a bad thing at first, but you have to consider that: - This allows for "memory restriction" features to stay on even when they should be turned off. And, even if this emulation makes the feature less effective, it's still better than having it turned off completely - The only code sequences emulated are trampolines used to make function calls. In many cases, when you have the chance to make arbitrary memory writes, you can already manipulate the control flow of the program by overwriting function pointers or return values. So, in many cases, the "trampoline emulation" doesn't introduce new exploit vectors. - It's a feature that can be turned on only if needed, on a per executable file basis. Thank your for taking the time to review this. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1497286620-15027-1-git-send-email-s.mesoraca16@gmail.com> <1497286620-15027-9-git-send-email-s.mesoraca16@gmail.com> From: Salvatore Mesoraca Date: Tue, 13 Jun 2017 09:41:29 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH 08/11] Creation of "pagefault_handler_x86" LSM hook To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com, Brad Spengler , PaX Team , Casey Schaufler , Kees Cook , James Morris , "Serge E. Hallyn" , x86@kernel.org, Ingo Molnar List-ID: 2017-06-12 19:32 GMT+02:00 Thomas Gleixner : > That explains, what you could do with it, but it completely lacks any > rationale WHY this is desired and good behaviour and how that is a security > feature. You are right, I could have been more descriptive. This is not a security feature "per se", it's a way to soften some unwanted side-effects of restrictive security features. In particular I'm trying to introduce a feature that will prevent the runtime creation of executable code in user-space programs: it's something like the PaX's MPROTECT feature. This hook is used to implement what PaX call "trampoline emulation" that, in practice, allow for some specific code sequences to be executed even if they are in non executable memory. This may look like a bad thing at first, but you have to consider that: - This allows for "memory restriction" features to stay on even when they should be turned off. And, even if this emulation makes the feature less effective, it's still better than having it turned off completely - The only code sequences emulated are trampolines used to make function calls. In many cases, when you have the chance to make arbitrary memory writes, you can already manipulate the control flow of the program by overwriting function pointers or return values. So, in many cases, the "trampoline emulation" doesn't introduce new exploit vectors. - It's a feature that can be turned on only if needed, on a per executable file basis. Thank your for taking the time to review this.