Hi Igor, On 8/14/21 3:39 PM, Igor Zhbanov wrote: > Hi Simon, > > пт, 13 авг. 2021 г. в 11:08, THOBY Simon <Simon.THOBY@xxxxxxxxxx>: >> 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
