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

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

On 3/18/26 12:38, Fabian Pflug wrote:
> 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.

I can't follow. policy is an argument and CONFIG_SECURITY_POLICY_INIT
is not settable from any board, so that's dead code now AFAICS.

Cheers,
Ahmad 

> 
>>
>>>
>>> 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);
>>>
>>
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |