Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   <masanobu2.koike@toshiba.co.jp>
To:     <penguin-kernel@I-love.SAKURA.ne.jp>, <casey@schaufler-ca.com>
CC:     <jmorris@namei.org>, <serge@hallyn.com>,
        <linux-security-module@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: RE: [RFC v2 1/2] WhiteEgret: Add WhiteEgret core functions.
Thread-Topic: [RFC v2 1/2] WhiteEgret: Add WhiteEgret core functions.
Thread-Index: AQHTssi2YobdO7JaGkut+ZrsdYcRG6PF4vNg
Date:   Thu, 8 Mar 2018 06:23:31 +0000
Message-ID: <TYXPR01MB18549C3215C503A8E1ACE459F1DF0@TYXPR01MB1854.jpnprd01.prod.outlook.com>
References: <20180301073830.2551-1-masanobu2.koike@toshiba.co.jp>
        <458a466a-78bc-80d4-4d52-64b92d39f416@schaufler-ca.com>
        <TYXPR01MB18540A7EDCE6F5BE8CFE130EF1C50@TYXPR01MB1854.jpnprd01.prod.outlook.com>
 <201803031722.EDF21804.QHMOtFJOFFOLSV@I-love.SAKURA.ne.jp>
In-Reply-To: <201803031722.EDF21804.QHMOtFJOFFOLSV@I-love.SAKURA.ne.jp>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
received-spf: None (protection.outlook.com: toshiba.co.jp does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 30d83ffa-a46b-4e02-0819-08d584bd1d4e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 06:23:31.7506
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0688
MSSCP.TransferMailToMossAgent: 103
X-OriginatorOrg: toshiba.co.jp
X-MAIL-FROM: <masanobu2.koike@toshiba.co.jp>
X-SOURCE-IP: [172.27.153.184]
X-Spam: exempt
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On Saturday, March 03, 2018 5:22 PM, Tetsuo Handa wrote:
> Masanobu Koike wrote:
> > On Friday, March 02, 2018 12:43 AM, Casey Schaufler wrote:
> > > On 2/28/2018 11:38 PM, Masanobu Koike wrote:
> > > > @@ -264,6 +266,9 @@ choice
> > > >  	config DEFAULT_SECURITY_APPARMOR
> > > >  		bool "AppArmor" if SECURITY_APPARMOR=3Dy
> > > >
> > > > +	config DEFAULT_SECURITY_WHITEEGRET
> > > > +		bool "WhiteEgret" if SECURITY_WHITEEGRET=3Dy
> > > > +
> > >
> > > I don't see this module using any security blobs. Is there
> > > a reason you're not making this a minor (like yama) module
> > > instead of a major (like AppArmor) module?
> >
> > Thank you for your suggestion.
> > We are now developing WhiteEgret on the environment
> > it works certainly.
> >
>=20
> ??? What Casey suggested is effectively
>=20
> ----------
> --- a/security/whiteegret/init.c
> +++ b/security/whiteegret/init.c
> @@ -48,9 +48,6 @@ static int __init we_init(void)
>  {
>  	int rc;
>=20
> -	if (!security_module_enable("whiteegret"))
> -		return 0;
> -
>  	security_add_hooks(we_hooks, ARRAY_SIZE(we_hooks),
> "whiteegret");
>=20
>  	rc =3D we_specific_init();
> ----------
>=20
> , isn't it? Unlike Yama, adding whiteegret_add_hooks() to security_init()
> is not useful, for security_init() is called too early to create security=
fs
> entries for WhiteEgret.
>=20
> Current version uses security=3D parameter as a switch for enabling/disab=
ling
> WhiteEgret, doesn't it? If WhiteEgret does not use security=3D as a switc=
h,
> is some other switch (e.g. __setup()) expected?

Sorry for the delay.
Thank you for your comment and suggestion.
I'll make this module a minor one in the
next version.

Masanobu Koike