Re: [PATCH 1/1] NAX LSM: Add initial support support

[THOBY Simon <Simon.THOBY@viveris.fr>]

Hi Igor,

On 8/14/21 3:39 PM, Igor Zhbanov wrote:
> Hi Simon,
> 
> пт, 13 авг. 2021 г. в 11:08, THOBY Simon <Simon.THOBY@viveris.fr>:
>> For the matter of have a kernel commandline being the result of concatenations from multiple
>> sources, I think that if any attacker is able to alter part of the command line, they can
>> already write 'lsm=' to it and completely disable NAX, thus I'm not sure 'nax_locked' should
>> impact other setup_* functions.
>>
>> I believe keeping the nax_locked parameter, but not checking for the 'locked' status in the other setup_*
>> functions should be enought, as sysctls writes will still be protected by the 'locked' variable.
> 
> I thought again about it. Currently it is possible to set parameters
> value in Kconfig, including "locked".
> So, if one needed some static configuration, that cannot be altered by
> any means, they can set
> the desired values at compilation time in Kconfig and it will be
> impossible to change it, nor by sysctl,
> nor by command-line.
> 
> But if I remove that (!locked) check, then the command-line options
> would alway be able to override
> the compile-time configuration, including unlocking the locked state.

That's a fair point, one way would probably be to replace "!locked" by
"!IS_ENABLED(CONFIG_SECURITY_NAX_LOCKED)" in the setup_*() functions, keeping
the compile-time override while preventing the commandline parameter ordering
issue we discussed.

However at this point I understand that you may find the current 'locked' usage easier,
and this whole discussion is probably nitpicking on my part.

> 
> Thank you.
> 

Thanks,
Simon