Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751540AbdFFOxB (ORCPT ); Tue, 6 Jun 2017 10:53:01 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:28096 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbdFFOw7 (ORCPT ); Tue, 6 Jun 2017 10:52:59 -0400 Subject: Re: [PATCH 4/5] Make LSM Writable Hooks a command line option To: Tetsuo Handa , , , , CC: , , , , , , References: <201706061954.GBH56755.QSOOFMFLtJFVOH@I-love.SAKURA.ne.jp> <6c807793-6a39-82ef-93d9-29ad2546fc4c@huawei.com> <201706062042.GAC86916.FMtHOOFJOSVLFQ@I-love.SAKURA.ne.jp> <4c3e3b8b-6507-7da5-1537-1e0ce04fcba5@huawei.com> <201706062336.CFE35913.OFFLQOHMtSJFVO@I-love.SAKURA.ne.jp> From: Igor Stoppa Message-ID: Date: Tue, 6 Jun 2017 17:51:26 +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: <201706062336.CFE35913.OFFLQOHMtSJFVO@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.0A020204.5936C1AE.02CD,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: e048bc0892a6220071d75ebe898d630d Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1147 Lines: 30 On 06/06/17 17:36, Tetsuo Handa wrote: > Igor Stoppa wrote: >> For the case at hand, would it work if there was a non-API call that you >> could use until the API is properly expanded? > > Kernel command line switching (i.e. this patch) is fine for my use cases. > > SELinux folks might want > > -static int security_debug; > +static int security_debug = IS_ENABLED(CONFIG_SECURITY_SELINUX_DISABLE); ok, thanks, I will add this > so that those who are using SELINUX=disabled in /etc/selinux/config won't > get oops upon boot by default. If "unlock the pool" were available, > SELINUX=enforcing users would be happy. Maybe two modes for rw/ro transition helps. > > oneway rw -> ro transition mode: can't be made rw again by calling "unlock the pool" API > twoway rw <-> ro transition mode: can be made rw again by calling "unlock the pool" API This was in the first cut of the API, but I was told that it would require further rework, to make it ok for upstream, so we agreed to do first the lockdown/destroy only part and the the rewrite. Is there really a valid use case for unloading SE Linux? Or any other security module. -- igor