[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Mar 2018 17:22:05 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: masanobu2.koike@...hiba.co.jp, casey@...aufler-ca.com
Cc: jmorris@...ei.org, serge@...lyn.com,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 1/2] WhiteEgret: Add WhiteEgret core functions.
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=y
> > >
> > > + config DEFAULT_SECURITY_WHITEEGRET
> > > + bool "WhiteEgret" if SECURITY_WHITEEGRET=y
> > > +
> >
> > 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.
>
??? What Casey suggested is effectively
----------
--- a/security/whiteegret/init.c
+++ b/security/whiteegret/init.c
@@ -48,9 +48,6 @@ static int __init we_init(void)
{
int rc;
- if (!security_module_enable("whiteegret"))
- return 0;
-
security_add_hooks(we_hooks, ARRAY_SIZE(we_hooks), "whiteegret");
rc = we_specific_init();
----------
, isn't it? Unlike Yama, adding whiteegret_add_hooks() to security_init()
is not useful, for security_init() is called too early to create securityfs
entries for WhiteEgret.
Current version uses security= parameter as a switch for enabling/disabling
WhiteEgret, doesn't it? If WhiteEgret does not use security= as a switch,
is some other switch (e.g. __setup()) expected?
Powered by blists - more mailing lists