-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making upgrades more reliable #61
Comments
Hi Nex, that fully applies only to the older version. The current version ("refactor") saves the existing registry keys before hardening (saving is done in registry below "SOFTWARE\Security Without Borders") and restores them when doing an "restore" (however it currently deletes registry keys that haven't been saved, because they didn't exist during hardening). What doesn't work right now:
TODOs:
|
Good points. What I rather meant though was also to make sure that when someone downloads a new version, and the computer was already hardened, that the user doesn't have to manually restore previous settings and then re-harden with the new version to have a clear run. This should rather be automatic. Does this make sense? |
Good point. I think we can implement this quite easily if the expert settings aren't used (just add a second button that does restore&harden in one step (with standard settings). Otherwise we would need some logic and/or changes in the GUI. |
@botherder Tried to implement that in a first version (quite ugly user interface - suggestions for improvements would be very nice). It just restores all settings first and then (currently) hardens all existing settings/modules. You can take a look at https://github.com/obsti8383/hardentools/releases/tag/0.4 |
Partly fixed by #66, still open: What doesn't work right now:
TODOs:
|
#69 fixed this: "If new registry keys are added to the hardening procedure in Hardentools and then a restore is started with that new version, registry keys might get deleted that have been there before (-> we also need to explicitly remember if registry keys haven't been there before." What still doesn't work:
TODOs:
|
#76 fixes possible upgrade and restores problems in Disallow Run hardening (cmd.exe, powershell(_ise).exe). It also only deletes the DisallowRun value itself, if no disallowed executables are left over. What still doesn't work:
TODOs:
|
#105 fixes restore functionality for registry keys. What still doesn't work:
TODOs:
|
I am wondering if it would be good to establish a process for people willing to run newer versions of the tool. At the moment, because of the way we developed, a user would be required to use the original version of the tool that was used to make the modifications to the system, revert those changes, download the new version and reapply the changes.
If the user deleted the copy of the original version of Hardentools, then they would need to figure out which had they actually used and download that. This seems quite impractical.
It would be good to identify a way that would allow us to keep a record on the system on the changes that have been and now to restore them. That could be just as simple .reg file stored in a persistent directory, to be invoked right before the execution of a new version of Hardentools.
Thoughts?
The text was updated successfully, but these errors were encountered: