From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750774AbdE0UKE (ORCPT ); Sat, 27 May 2017 16:10:04 -0400 Received: from mail-it0-f42.google.com ([209.85.214.42]:36768 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbdE0UKB (ORCPT ); Sat, 27 May 2017 16:10:01 -0400 MIME-Version: 1.0 In-Reply-To: <20170527084135.GA26844@infradead.org> References: <1495829844-69341-1-git-send-email-keescook@chromium.org> <1495829844-69341-6-git-send-email-keescook@chromium.org> <20170527084135.GA26844@infradead.org> From: Kees Cook Date: Sat, 27 May 2017 13:09:59 -0700 X-Google-Sender-Auth: Kev6K2lEvvvtVKdLK2Jz2o59DAY Message-ID: Subject: Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast To: Christoph Hellwig Cc: "kernel-hardening@lists.openwall.com" , Tetsuo Handa , James Morris , Laura Abbott , "x86@kernel.org" , LKML , linux-security-module Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 27, 2017 at 1:41 AM, Christoph Hellwig wrote: > On Fri, May 26, 2017 at 01:17:09PM -0700, Kees Cook wrote: >> The LSM initialization routines walk security_hook_heads as an array >> of struct list_head instead of via names to avoid a ton of needless >> source. Whitelist this to avoid the false positive warning from the >> plugin: > > I think this crap just needs to be fixed properly. If not it almost > defeats the protections as the "security" ops are just about everywhere. There's nothing unsafe about 3dfc9b02864b19f4dab376f14479ee4ad1de6c9e, it just avoids tons of needless code. Tetsuo has some other ideas for cleaning it up further, but I don't like it because it removes compile-time verification of function types. There have been a lot of trade-offs in getting this working correctly, so I don't have any problem with how it looks currently. It's just a collision of assumptions between randstruct (omg, you're accessing a randomized struct with a different struct!) and the security head list (all entries are lists, and we're just initializing them). -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Sat, 27 May 2017 13:09:59 -0700 Subject: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast In-Reply-To: <20170527084135.GA26844@infradead.org> References: <1495829844-69341-1-git-send-email-keescook@chromium.org> <1495829844-69341-6-git-send-email-keescook@chromium.org> <20170527084135.GA26844@infradead.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Sat, May 27, 2017 at 1:41 AM, Christoph Hellwig wrote: > On Fri, May 26, 2017 at 01:17:09PM -0700, Kees Cook wrote: >> The LSM initialization routines walk security_hook_heads as an array >> of struct list_head instead of via names to avoid a ton of needless >> source. Whitelist this to avoid the false positive warning from the >> plugin: > > I think this crap just needs to be fixed properly. If not it almost > defeats the protections as the "security" ops are just about everywhere. There's nothing unsafe about 3dfc9b02864b19f4dab376f14479ee4ad1de6c9e, it just avoids tons of needless code. Tetsuo has some other ideas for cleaning it up further, but I don't like it because it removes compile-time verification of function types. There have been a lot of trade-offs in getting this working correctly, so I don't have any problem with how it looks currently. It's just a collision of assumptions between randstruct (omg, you're accessing a randomized struct with a different struct!) and the security head list (all entries are lists, and we're just initializing them). -Kees -- Kees Cook Pixel Security -- 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 Sender: keescook@google.com In-Reply-To: <20170527084135.GA26844@infradead.org> References: <1495829844-69341-1-git-send-email-keescook@chromium.org> <1495829844-69341-6-git-send-email-keescook@chromium.org> <20170527084135.GA26844@infradead.org> From: Kees Cook Date: Sat, 27 May 2017 13:09:59 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast To: Christoph Hellwig Cc: "kernel-hardening@lists.openwall.com" , Tetsuo Handa , James Morris , Laura Abbott , "x86@kernel.org" , LKML , linux-security-module List-ID: On Sat, May 27, 2017 at 1:41 AM, Christoph Hellwig wrote: > On Fri, May 26, 2017 at 01:17:09PM -0700, Kees Cook wrote: >> The LSM initialization routines walk security_hook_heads as an array >> of struct list_head instead of via names to avoid a ton of needless >> source. Whitelist this to avoid the false positive warning from the >> plugin: > > I think this crap just needs to be fixed properly. If not it almost > defeats the protections as the "security" ops are just about everywhere. There's nothing unsafe about 3dfc9b02864b19f4dab376f14479ee4ad1de6c9e, it just avoids tons of needless code. Tetsuo has some other ideas for cleaning it up further, but I don't like it because it removes compile-time verification of function types. There have been a lot of trade-offs in getting this working correctly, so I don't have any problem with how it looks currently. It's just a collision of assumptions between randstruct (omg, you're accessing a randomized struct with a different struct!) and the security head list (all entries are lists, and we're just initializing them). -Kees -- Kees Cook Pixel Security