From mboxrd@z Thu Jan 1 00:00:00 1970 From: sargun@sargun.me (Sargun Dhillon) Date: Thu, 7 Dec 2017 16:14:58 -0800 Subject: [RFC 0/3] Safe, dynamically (un)loadable LSMs 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> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 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 > > -- 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