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

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

Hi,

On 3/18/26 1:47 PM, Fabian Pflug wrote:
> On Wed, 2026-03-18 at 12:54 +0100, Ahmad Fatoum wrote:
>> 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.
> 
> policy is the argument, but the argument could be NULL, for example if `IS_ALLOWED` is used in the code.
> Then policy is replaced by active_policy, which could also be NULL, if `security_policy_get(CONFIG_SECURITY_POLICY_INIT)
> ` during init returns NULL, which is the case, if the policy is not registered at the time of call.
> During security_init only CONFIG_SECURITY_POLICY_PATH are registered. So for example, you could add multiple policys
> with `security_policy_add` inside your boardcode and have one of them declared as init policy with
> CONFIG_SECURITY_POLICY_INIT. Then this path is taken during the first call to `IS_ALLOWED` (after board init)

I talked it over with Fabian. I see now what I misunderstood: The policy
is selected only if it exists. If it's not registered yet, we still need
the later policy select.

Still, I feel this complicates the logic more than I'd like.

Instead we can factor out the CONFIG_SECURITY_POLICY_INIT logic in
is_allowed into security_policy_ensure (or some better name) and then
call that explicitly on entry to functions that expect the policy
selection to be settled.

Cheers,
Ahmad

> 
> Kind regards
> Fabian
>>
>> 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 |