Allow admins to set individual security settings without taking away all ability for users to make other adjustments themselves

[klopeksbackyard]

As far as I understand it, I can use "C:\Program Files\SumatraPDF\sumatrapdfrestrict.ini" to harden SumatraPDF. However, once this file exists, users can no longer make any of their own advanced settings (in "SumatraPDF-Settings.txt"), even those settings that aren't supposed to be enforced via the INI file.

What I need as an admin is the ability to enforce certain settings while still leaving users room to maneuver with others.

This becomes especially relevant when it comes to security-critical settings. In the prebuild version, I saw the "JavaScript" parameter — if SumatraPDF adds JavaScript support in the future, then I MUST be able to control/disable that centrally, without preventing users from making non-critical adjustments themselves.

[kjk]

Yeah, sumatrapdfrestrict.ini was designed for kiosk-like usage, not really for the enterprise install scenario.

I'm not opposed to this but I have no experience to make good decisions here so you would have to provide more detailed design i.e. how to configure this restriction (would probably be best done via something else than sumatrapdfrestrict.ini) and what settings should be configurable.

[klopeksbackyard]

For Windows-Domain-Environments, Group Policies would be perfect. But that would probably be a lot of work for you. Registry-Keys would also be very practical for a Windows-Domain-Environment - usually HKEY_CURRENT_USER\Software\SumatraPDF would be all the settings, users are allowed to change themselves, whereas HKEY_LOCAL_MACHINE\SOFTWARE\Policies\SumatraPDF would contain the settings that are enforced. It would be great if all the settings (see below) could be used in either place - and "Policies" would be "stronger".

If it is too complicated using Group Policies or Registry, I could also live with two different INI/TXT-files. If I could use all parameters in either file and if the restrict.ini-parameters would enforce, whereas the txt-parameters still would be changeable - that would be perfect.

Example:
INI contains "ShowLinks = true" --> User can't change "ShowLinks" in his/her TXT.
INI contains multiple entries but nothing about "ShowLinks" --> User can change "ShowLinks" in his/her TXT

AllowExternalImages = false
CheckForUpdates = false
DisableAutoLinks = true
DisableJavaScript = true
ShowLinks = true

[klopeksbackyard]

Basically, one need two config-files or config-keys in two different locations.
One, where users can change it, one, where users only can read, but not write.
The ones where users can only read, would be the settings, that are enforced.
The set of parameters could be identical in both places.

[klopeksbackyard]

I can also name settings, which I think should be enforceable.

Those here spring to mind:

AllowExternalImages = false
CheckForUpdates = false
DisableAutoLinks = true
DisableJavaScript = true
ShowLinks = true
EnableTeXEnhancements = false
RememberOpenedFiles = true
RememberStatePerDocument = true
RestoreSession = true

CheckForUpdates - because admins often use deploymenttools
Links/Java/ExternalImages - because of security
Recent Files - because of privacy [personally, I don't mind, but this is typically something, dataprotection-people would want]

[kjk]

Implementation effort is not the issue. I know there is such a thing like Group Policies but I have no idea how it's supposed to work.

Can you point to a short youtube tutorial or describe how an admin sets group policies for a given program?

[rmmbr]

I like the approach taken by the password manager KeePass. It uses an optional file named "KeePass.config.enforced.xml," which is saved with administrator privileges in the "c:\Program Files\KeePass Password Safe 2" directory. The user configuration is then merged in according to straightforward rules. This approach is very lightweight, has proven effective, and is completely optional to set up. Configuration documentation can be viewed here.

[rmmbr]

A brief additional note: I have already encountered KeePass on multiple occasions in a professional context specifically in security-critical enterprise deployment scenarios using the configuration described.

[kjk]

@rmmbr KeePass method makes sense and would be relatively easy to add.

I just watched how setting Group Policy for Chrome works and it's just insanity

[rmmbr]

@rmmbr KeePass method makes sense and would be relatively easy to add.

@kjk : ... and clean and easy to deploy and easy for the enduser and secure with Windows-security and ...