Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752452AbdLHAPl (ORCPT ); Thu, 7 Dec 2017 19:15:41 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:46815 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752259AbdLHAPj (ORCPT ); Thu, 7 Dec 2017 19:15:39 -0500 X-Google-Smtp-Source: AGs4zMYsDk2iXgwY67DI0rYYX1hkJwX8GwlbUnNBnLFe0epw9dWaRnMf6Qc0dOJCZXeSE1wQjg1rWTwuAKxYSW2rTiM= MIME-Version: 1.0 In-Reply-To: References: <20171126221545.GA13751@ircssh-2.c.rugged-nimbus-611.internal> <8c8dd781-d30a-7105-011d-127cf5188426@schaufler-ca.com> <866f86cf-d28a-3da7-4a2d-cbc5a330bd4a@schaufler-ca.com> From: Sargun Dhillon Date: Thu, 7 Dec 2017 16:14:58 -0800 Message-ID: Subject: Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs To: James Morris Cc: Casey Schaufler , LSM , Kees Cook , Igor Stoppa , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1244 Lines: 32 On Wed, Dec 6, 2017 at 4:00 PM, James Morris wrote: > On Wed, 6 Dec 2017, Sargun Dhillon wrote: > >> Should I respin this patch sans module unloading? Still a set of dynamic >> hooks that are independent to allow for sealable memory support. > > Yes, please. > >> I'm also wondering what people think of the fs change? I don't think >> that it makes a lot of sense just having one giant list. I was thinking >> it might make more sense using the module_name instead. > > I don't know how useful this will be in practice. Who/what will be > looking at these entries and why? For the same reason you look at iptables -L -n -- to figure out what's being invoked, and what's causing rejections (or falsely accepting requests). In addition, this is for minor LSMs, so the traditional /sys/kernel/security/lsm doesn't make a lot of sense in my opinion, as it's not broken out per-hook. Given that this can be registered per-hook, versus globally, I think that breaking out the LSMs per hook makes more sense. It also can be used to determine if a hook was loaded after boot, if the global invocations is greater than the invocations of the instance of that hook. > > > -- > James Morris > >