Re: [PATCH v3 3/5] security: policy: set active policy on boot

[Fabian Pflug <f.pflug@pengutronix.de>]

On Wed, 2026-03-18 at 12:28 +0100, Ahmad Fatoum wrote:
> On 3/18/26 10:22, Fabian Pflug wrote:
> > If init name has been set at compiletime and the policy is available,
> > because it is part of the path, then set the active policy to the policy
> > selected by compiletime.
> > Since this is so early in the bootchain, there is no need to call
> > security_policy_activate, because there should not be any registered
> > callbacks at this moment in time.
> > If no policy could be found, then it will be filled as before by the
> > first call to is_allowed.
> 
> The code in is_allowed is:
> 
> if (!policy && *CONFIG_SECURITY_POLICY_INIT) {
>         security_policy_select(CONFIG_SECURITY_POLICY_INIT);
>         policy = active_policy;
> }
> 
> It becomes dead code with your change here as CONFIG_SECURITY_POLICY_INIT
> is a compile-time constant, there is no filling on the first call anymore.

I also thought about it, but if the initial policy is not part of the compiletime policies, but instead gets added
during board setup code, then the change in init will not find the specified policy, resulting in policy being NULL and
this code still working.

> 
> > 
> > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > ---
> >  security/policy.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/security/policy.c b/security/policy.c
> > index 85333d9e6f..e2d1b10a78 100644
> > --- a/security/policy.c
> > +++ b/security/policy.c
> > @@ -235,6 +235,9 @@ static int security_init(void)
> >  	if (*CONFIG_SECURITY_POLICY_PATH)
> >  		security_policy_add(default);
> >  
> > +	if (*CONFIG_SECURITY_POLICY_INIT)
> > +		active_policy = security_policy_get(CONFIG_SECURITY_POLICY_INIT);
> > +
> 
> I think I decided initially against this, because there was initially
> a Sconfig option against changing the active security policy.
> 
> I believe now a single option is too limiting, it should instead be
> a directed graph that explains which policies are reachable from a given
> policy.
> 
> Anyways, the change here invalidates the Kconfig help text for
> SECURITY_POLICY_INIT.
> 
> I am not fully sure if this change is a good idea, but it needs to
> be fixed to be considered. I assume you do this, because checking
> the name of the policy doesn't trigger a selection like IS_ALLOWED does?

exactly.
during device_probe, there is a need to know the current policy name, if there is a policy active.

I will have a look into it.

Fabian

> 
> Thanks,
> Ahmad
> 
> 
> >  	return 0;
> >  }
> >  pure_initcall(security_init);
> > 
>