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

Hi Igor,

On 8/14/21 3:39 PM, Igor Zhbanov wrote:

Hi Simon,

пт, 13 авг. 2021 г. в 11:08, THOBY Simon [off-list ref]:

quoted

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