Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751444AbdFFJCQ (ORCPT ); Tue, 6 Jun 2017 05:02:16 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:28060 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbdFFJCO (ORCPT ); Tue, 6 Jun 2017 05:02:14 -0400 Subject: Re: [PATCH 4/5] Make LSM Writable Hooks a command line option To: Tetsuo Handa , , , , CC: , , , , , , References: <20170605192216.21596-1-igor.stoppa@huawei.com> <20170605192216.21596-5-igor.stoppa@huawei.com> <71e91de0-7d91-79f4-67f0-be0afb33583c@schaufler-ca.com> <201706060550.HAC69712.OVFOtSFLQJOMFH@I-love.SAKURA.ne.jp> From: Igor Stoppa Message-ID: Date: Tue, 6 Jun 2017 11:58:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <201706060550.HAC69712.OVFOtSFLQJOMFH@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59366F86.007E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 94754c51b1d332616a3028ca98c078d7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1203 Lines: 42 On 05/06/17 23:50, Tetsuo Handa wrote: > Casey Schaufler wrote: [...] >> I don't care for calling this "security debug". Making >> the lists writable after init isn't about development, >> it's about (Tetsuo's desire for) dynamic module loading. >> I would prefer "dynamic_module_lists" our something else >> more descriptive. > > Maybe dynamic_lsm ? ok, apologies for misunderstanding, I'll fix it. I am not sure I understood what exactly the use case is: -1) loading off-tree modules -2) loading and unloading modules -3) something else ? I'm asking this because I now wonder if I should provide means for protecting the heads later on (which still can make sense for case 1). Or if it's expected that things will stay fluid and this dynamic loading is matched by unloading, therefore the heads must stay writable (case 2) [...] >>> + if (!sec_pool) >>> + goto error_pool; >> >> Excessive gotoing - return -ENOMEM instead. > > But does it make sense to continue? > hook_heads == NULL and we will oops as soon as > call_void_hook() or call_int_hook() is called for the first time. Shouldn't the caller check for result? -ENOMEM gives it a chance to do so. I can replace the goto. --- igor