Provide "secure" setting in HKLM so users cannot modify thier configuration

[alexhass]

I'm reading these words in https://download.nvaccess.org/documentation/userGuide.html#SecureMode

Installed copies of NVDA store their configuration including add-ons in %APPDATA%\nvda. To prevent NVDA users from modifying their configuration or add-ons directly, user access to this folder must also be restricted.

and I'm a bit shocked what type of security you are implementing. Restricting access to "%APPDATA%\nvda" is not really useful. No idea how we should do this.

Please add a simple registry key to "HKEY_LOCAL_MACHINE\SOFTWARE\NVDA" so users cannot change it - e.g. secureMode=1.

Than admins can set this value via GPO or other ways to secure the config. This would be simple thing compared to restricting access to a folder.

[alexhass]

Asking me if HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\nvda\forceSecureMode = 1 does not require the access restriction?

In this case the documentation requires an update and additional hints.

[seanbudd]

it does require the access restriction

[alexhass]

This is not useful. If I configure a force setting, why can this bypassed? That is a serious security issue if it can bypassed. Read the registry flag and than stop reading the config from appdata folder and all is solved?

[seanbudd]

I'm not sure I understand this request.

Yes, you can force secure mode with that registry key.
However, if you do not restrict access to %APPDATA%\nvda then this restriction can be bypassed by modifying config such as adding arbitrary code as add-ons.

There's many different ways of changing the read-write access of folders in Windows. How you implement this really depends on how you are deploying Windows.

[alexhass]

This is not logic to me. I configure forceSecureMode in HKLM. Than - nothing must be able to override or bypass this machine setting. Once the setting is enforced, the user setting folder should no longer used / read. Using the registry for all settings would be much better as GPOs can be enforced and a user cannot change enforced settings. So no bypass is possible anymore.

„access bypass“ makes it a critical security bug that requires immediate actions and a new release with fixes included.

[seanbudd]

We have proposed #16599 to create the ability for more refined access restrictions to config.
Using the registry for all settings is not entirely possible - for example add-ons are custom code which is not as simple as a registry key.

We do not view this as a critical security bug. Secure mode is well documented on how to implement it correctly. If you set up secure mode correctly, there should be no security issues.

[josephsl]

Hi,

The reason for using %appdata% and other paths to store config data is because a user can transform NVDA into a portable application on a USB drive. The biggest advantage is that a user has portable copy of NVDA complete with their own settings (including not checking for updates), and to account for installing NVDA on a computer and using it without installing, configuration paths are used. Put it the other way, accessing registry (HKLM or HKCU hives) to read and write settings require installing NVDA, and using this database for portable version of NVDA defeats this purpose.

Further, remember that data recorded in HKLM hive applies to the machine itself, and that is where global settings such as update checks should be stored if the IT team wants to enforce no update checks across the entire domain/organization (this poses a different issue when it comes time to update NVDA, something I think we have discussed in the past). If you want users to store settings on the registry, HKCU is a more appropriate hive.

Thanks for understanding.