Here is the H_C FAQ opened for discussion (added some important questions). I would like to thank @oldschool for the patience and insightful corrections.
Some FAQs will be especially interesting when using SUA (installation/updating applications).
Acronyms used in FAQs:
H_C - Hard_Configurator
SRP - Software Restriction Policies (Windows built-in)
UAC - User Account Control
SUA - Standard User Account
AA - Administrator Account (that should not be confused with full Administrator Account, which is disabled by default).
Standard rights (standard user rights)
They are the standard (default) rights granted by the Windows system to the processes initiated by the user on AA or SUA. Executables started by the user are restricted by User Account Control (UAC). They run initially with standard rights only. This feature was introduced with Windows Vista. In fact, the Administrator Account (AA) created during a fresh installation of Windows or created manually by the user, is limited to standard rights by UAC.
Administrator rights (Administrative rights)
A process initiated by the user on AA or SUA can elevate to Administrator rights. Some important, new privileges are granted to a process running with Administrator rights. If the elevated process was initiated on AA (with standard rights), then process creation and elevation take place on AA, and the process continues to run on AA (account change not required). If it is initiated on SUA, then process creation and elevation also take place on AA, so the process no longer runs on SUA (account change SUA ---> AA, admin password required). Process elevation is controlled by User Account Control (UAC).
H_C smart default-deny setup
Selected Windows built-in policies and security settings can restrict Windows, MS Office, and Adobe Acrobat Reader with smart default-deny protection. This protection is configurable with the H_C application, which also displays the actual state of applied settings. Real-time protection comes from Windows' built-in security features and is independent of H_C application.
SystemSpace
File locations (folders and subfolders) which are whitelisted by default in H_C:
C:\Windows, C:\Program Files, C:\Program Files (x86) - only on Windows 64-bit, C:\ProgramData\Microsoft\Windows Defender.
UserSpace
All locations on the user's local drives (also USB external drives) which are not in the SystemSpace. This does not include network locations. UserSpace locations are writable by processes running with standard rights. The only restrictions follow from Windows' isolation of each user profile. All executables in the UserSpace are blocked by default, except when whitelisted or "Run As SmartScreen", while using H_C's smart default-deny.
Normally, the user can initiate applications
only with standard rights. But this can be changed by using an elevated shell: PowerShell (Administrator), Command Prompt (Administrator), etc. An alternative solution is to run Total Commander via "Run As SmartScreen".
By using an elevated shell, the user can initiate applications with Administrator rights. This is a convenient solution when doing administrative work on the computer, because the user has to use "Run As SmartScreen" (and accept UAC) only once when accessing an elevated shell. As long as the applications are initiated this way, SRP and UAC will ignore them (no UAC alerts
or SRP restrictions).
PLEASE NOTE: The words
SystemSpace and
UserSpace are specific to H_C settings. They should not be confused with the words
‘System Space’ and
‘User Space’, which can have a more general meaning.
What is conventional default-deny protection?
It allows all installed applications and system processes, but blocks by default all new executables (even non-malicious).
Every new executable must first be whitelisted by the user in order to run. It is the user's responsibility to whitelist files which are safe.
What are the advantages of H_C's smart default-deny vs conventional default-deny protection?
It allows running some new executables without whitelisting, while safely bypassing default-deny protection. Smart default-deny makes the computer more usable, while maintaining a high level of protection in the home environment.
There are three smart features, which were adopted in H_C default-deny setup:
- Forced SmartScreen (Administrator rights), which can be activated by the setting <Run As SmartScreen> = Administrator. Forced SmartScreen is supported on Windows 8, 8.1, and 10.
- SRP set to allow executables started with Administrator rights.
- SystemSpace whitelisted by default .
Some files in C:\Windows may be blacklisted by the user when using <Block Sponsors> settings.
Are H_C's smart features safe?
They are pretty safe in the home environment, against malware in the wild.
Smart features can be bypassed in Enterprises because of targeted attacks. Also, important restrictions like remote features, cannot be blocked in Enterprises.
Will H_C smart default-deny setup block system processes, Windows Updates, and system scheduled tasks?
No, it will not. System processes, Windows Updates, and system scheduled tasks are not started directly by the user. Furthermore, they are started with higher than standard rights and can automatically bypass SRP restrictions which are used in H_C default-deny setup.
Will H_C smart default-deny block updates of user applications?
Yes, sometimes it will. Many applications simply download the update executable and run it from the Temp folder with standard rights. In this case, the update will be blocked in the H_C default-deny settings.
How to update users' applications on Administrator account with H_C's default-deny settings?
If the update is blocked, then the application or update executable has to be run with Administrator rights, by using "Run As SmartScreen" (on Windows 8, 8.1, 10) or "Run as administrator" (on Windows Vista or Windows 7).
How to update users' applications on SUA with H_C's default-deny settings?
There can be a problem only If the application is installed in the
user profile, because then it cannot be executed with Administrator rights. Why? When running with Administrator rights, the update will usually search the application files in administrator profile, and not in SUA profile.
The update will fail or will be installed in the wrong user profile.
- If the application is not installed in the user profile, then the update can be done on Administrator account as described above.
- If the application is installed in the user profile (e.g. in the folder C:\Users\Alice when the user name is Alice), then the user must:
- turn OFF protection temporarily using "Switch Default-Deny";
- run the update;
- turn ON the protection using "Switch Default-Deny".
Is it safe to whitelist the SystemSpace?
Generally, it is pretty safe in smart default-deny setup. SystemSpace locations are usually not writable with standard rights. The exploit or malware cannot silently drop payloads to the SystemSpace when running with the standard rights. There are known exceptions, but these are forbidden in H_C by the <Protect Windows Folder> setting.
Are all applications installed in the SystemSpace?
They should be, and this is recommended by Microsoft. In practice, some legal applications still install to the folders in the UserSpace. These applications have to be whitelisted manually by the user. If the user frequently installs such applications, then default-deny protection is an inconvenient solution.
What is the difference between an AA and SUA?
Processes initiated by the user
cannot run with Administrator rights on SUA. If a process running on SUA requires Administrator rights, then the UAC prompt appears, and the user must provide an Administrator password to log on to the AA. After accepting the UAC, the process is no longer running on SUA, but on AA (user account is changed for that process: SUA ---> AA).
This behavior is quite different when the user starts the process on AA. The UAC prompt is also visible, but the user is not required to provide the Administrator password. Instead, the UAC prompt asks for a simple "Yes" or "No". After accepting the UAC prompt, the process continues running on the same AA (user account is not changed for that process).
Is SUA more secure than AA?
Yes, most definitely. On SUA, unelevated processes (running with standard rights or lower) do not share the same account as elevated processes. This is not true on AA. It is much easier to exploit something when both unelevated and elevated processes are running on the AA account.
Malware or exploits cannot run with Administrator rights on SUA - they must first escape from SUA to an Administrator account. Most malware samples are not prepared to do this. Additionally, Microsoft usually patches these rare system vulnerabilities, which might allow malware to escape from SUA. H_C's smart default-deny setup relies on blocking unelevated applications (running with standard rights), so SUA is an ideal companion to H_C.
When should SUA be used instead of AA?
SUA should be considered a vital part of any security solution, when using
a vulnerable system, or popular & vulnerable software. However, it is not necessary to use SUA with H_C's smart default-deny when Windows 10 and all installed software are kept updated regularly. Such a setup is a dead end for malware/exploits in the home environment.
Does Forced SmartScreen work well on SUA?
Yes, if the application installs in the SystemSpace (usually in C:\Program Files). There can be a problem if it installs in the user profile, which lies in the UserSpace. Why? Because with H_C smart default-deny, Forced SmartSreen uses Administrator rights. Applications which are intended to install in the SUA profile, are installed in the Administrator profile - even when the installation is initiated from SUA. The user on SUA cannot access the Administrator profile, and will not be able to run the application. In this case, the user must disable default-deny protection temporarily, and install the application without "Run As SmartScreen".
How to install applications on SUA?
- Run the application installer by using "Run As SmartScreen" option from the Explorer right-click context menu.
- Choose custom configuration in application installer to check the default installation folder.
- If it is in the Administrator profile, then cancel the installation and continue with Steps #4-7. If not, then continue with the installation and skip Steps #4-7.
- Use 'Switch Default-Deny' to turn OFF the protection temporarily.
- Install the application normally (by left mouse-click or pressing the Enter key).
- Whitelist the application in the UserSpace.
- Use 'Switch Default-Deny' to turn ON the protection.
Why Recommended H_C settings are best as a starting setup?
New users of default-deny protection should be aware that it requires more skill than using an AV alone. Please use
only the Recommended H_C settings along with an AV, until you are comfortable and familiar with it. Prematurely adding advanced H_C settings or more security software to this configuration may lead to complications, and user discouragement, with default-deny protection.
Who should consider applying advanced H_C settings?
The Recommended H_C settings can apply preventive protection. They are suited to prevent running malware in the system.
The advanced H_C settings can apply additional mitigations, when malware or an exploit is already running in the system. When using well-patched software on updated Windows 10, advanced settings are not required.
Will advanced settings spoil the system?
On most computers, even maximum H_C settings cannot break anything important in the system, but some applications may be not fully functional. The maximum protection usually requires more whitelisting, more researching of logs, etc., and may be annoying for most users. If so, then the user should restore the Recommended settings.
How can one restore the Recommended settings?
When the user has problems with advanced settings, there is an easy way to restore the Recommended settings:
- Press <Recommended SRP> left panel button,
- Press <Recommended Restrictions> right panel button,
- Press <APPLY CHANGES> button.
Restoring the Recommended settings preserves the user's whitelisted entries and blocked file extensions.
PLEASE NOTE:
If SRP is initially deactivated, then order of the pressed buttons is important! Pressing the buttons in another order (for example 2,1,3) will forbid installation of new applications. This kind of a locked setup is much more restricted as compared to Recommended settings.
How should one apply advanced H_C settings?
The advanced settings can be activated by turning ON additional individual H_C options, or by loading the setting profile (<Load Profile> button).
It is advisable to begin with the Recommended_Enhanced profile. This may be done by loading the file: Windows_*_Recommended_Enhanced.hdc, where the asterisk can be the Windows version (7, 8, or 10). This will configure the Recommended settings, and some well known Sponsors will be blocked (including Script Interpreters).
PLEASE NOTE: It is not advisable to use multiple advanced settings at once. When using advanced settings, the user should occasionally check for blocked entries (<Tools><Blocked Events / Security Logs>). This is because there is sometimes no alert when a process is blocked by Windows policies.
What is a Sponsor?
A Sponsor is an executable from the SystemSpace (usually from C:\Windows), that can be used by an attacker to bypass default-deny protection. Sponsors are frequently used in targeted attacks on organizations and businesses, especially via exploits. Blocking some Sponsors in the home environment can be important for people who use either a vulnerable system and/or software. In H_C's Recommended settings, Windows Script Host Sponsors (wscript.exe and cscript.exe) are forbidden by SRP. PowerShell Sponsors (powershell.exe and powershell_ise.exe) are restricted by Constrained Language mode in Windows 10 and blocked by SRP in Windows Vista, 7, 8, 8.1. These Sponsors are the most popular examples of Script Interpreters. Some other Interpreters (mshta.exe, hh.exe, wmic.exe, scrcons.exe) can be blocked in H_C by <Block Sponsors> option. Unfortunately, a few of them can be used occasionally by older software, usually including those related to peripherals. Applications and web browser plugins may also use Interpreters for some actions, though most applications and plugins do not use them at all.
In H_C, Sponsors are blocked for processes running with standard rights, but allowed for administrative processes running with higher rights.
Can wildcards be used for whitelisting files and folders?
Yes, they can. Here are some examples, where the random characters are replaced by wildcards to whitelist the particular EXE file:
Code:
C:\Users\Alice\Fly2theMoon\App.1928327467-092837\setup_101989873.exe
C:\Users\Alice\Fly2theMoon\App.??????????-??????\setup_?????????.exe
C:\Users\Alice\Fly2theMoon\App.*\setup_?????????.exe
C:\Users\Alice\Fly2theMoon\App.*\setup_*.exe
C:\Users\Alice\Fly2theMoon\App.*\*
Those rules (except the first) are correct, and the EXE file will be whitelisted even when the random numbers will change after some time. The last rule is most general, because it will whitelist many other files and folders, for example:
C:\Users\Alice\Fly2theMoon\App.malware\virus.js
