Defence+ (HIPS) vs dedicated user account with proper filesystem permissions

Hi all there! For many years I used a classical protection scheme based on dedicated user accounts and filesystem permissions. E.g. under Windows OSes for my web browser ‘FirefoxPortable’ app there was dedicated account created (named also ‘FirefoxPortable’) with only allowed write access to:

  • Firefox’s profile dir;
  • ‘FirefoxPortable’ account home folder (i.e. C:\Users\FirefoxPortable).
    All other places are allowed to read only.

So, if the app becomes infected somehow in general case (when no elevation/impersonalization occuring), it only can damage places mentioned above, which are not so significant.

Alternatively, with Comodo HIPS we can create rules to get close behaviour. HIPS allows to monitor filesystem (amoung other things), so entire filesystem maybe set as read-only with particular writable folders on per app basis. That is fine instrument to control write access (e.g. for a browser app it’s only allowed to write to profile and downloads dirs).

Below there are HIPS advantages/disadvanteages I found at the moment:

Advantages:

  1. No dedicated system accounts and special NTFS permissions required. FAT filesystem might be used as well.

  2. Running the same app from ‘admin’ account (priviledges elevation) does not break the protection. All protected resources are still protected (at least, conceptually).

Disadvantages:

  1. HIPS might fail to start for some reason (or you just turned it off with GUI command) - that leads no protection at all.

  2. Child process does not inherit parent process permissions. So, if an app uses auxilary system process (which is trusted) or some trusted apps to modify files, there is no protection.

  3. When replacing a file in protected area a dialog about replace confirmation appears, then (after confirmation) the file does not overwrire, but no user dialog about write impossibility appears.

  4. Bug?: when file is marked as ‘Unrecognized’ by user and such file is known as safe for HIPS (e.g. it’s listed in Comodo safe list), then file is treated as safe by HIPS rules regardless user specification. This means that explicit ‘Block’ action is needed in a rule ( ‘Ask’ action will allow access for safe apps). Having no ‘Ask’ action makes impossible asking messages.

  5. Bug: In HIPS rules pathes like %userprofile%..\TeamViewerPortable* (notice “…” part) don’t work.

  6. Bug: If running an app from another user’s account (e.g. with “runas” command) user environment variables like %userprofile% do not change to that user. So, must be specified explicitly in HIPS rules, e.g.: C:\Users\TeamViewerPortable*, but no %userprofile%*.

I was using HIPS in safe mode. It was Comodo Firewall v10.2.

I’m interesting if someone has more or less rich experience of using HIPS - which other advantages/disadvantages were found?

Personally me prefer dedicated user account - it’s a more simple way. HIPS configuration process is complex - so mistakes are very possible that breaks the defence.

Of course, these both ways are not mutually exclusive, so for best protection both can applied simultaneously.

3. When replacing a file in protected area a dialog about replace confirmation appears, then (after confirmation) the file does not overwrire, but no user dialog about write impossibility appears.
I'm not sure how you mean it doesn't, but you do get an access denied error message from windows when you try to write to a blocked location that is defined in the HIPS rule for that application. You will also see the blocked event in HIPS event logs.
4. Bug?: when file is marked as 'Unrecognized' by user and such file is known as safe for HIPS (e.g. it's listed in Comodo safe list), then file is treated as safe by HIPS rules regardless user specification. This means that explicit 'Block' action is needed in a rule ( 'Ask' action will allow access for safe apps). Having no 'Ask' action makes impossible asking messages.
Yes a bug that will be fixed in an upcoming release. You can however set HIPS to paranoid mode to get alerts for application regardless of file rating.
5. Bug: In HIPS rules pathes like %userprofile%\..\TeamViewerPortable\* (notice ".." part) don't work.
Not a valid file path so not a bug, you should use the wildcard character in place of the dots.
6. Bug: If running an app from another user's account (e.g. with "runas" command) user environment variables like %userprofile% do not change to that user. So, must be specified explicitly in HIPS rules, e.g.: C:\Users\TeamViewerPortable\*, but no %userprofile%\*.
Sounds like a bug with Windows as Windows is what sets up the environment variables, though I haven't tested it yet.

Hi futuretech, thanks for joining and clarification.

Windows operates correctly, e.g.:

runas /user:FooUser cmd

then after entering FooUser’s password FooUser’s console appears, typing there for example

echo %userprofile%

gives right result.

When Comodo processes HIPS rules of an app launched like above, it handles environment variables (like %userprofile%) incorrectly - it uses ones belonging to original user (who invoked “runas”).

In particular, “Temporary Files” file group lists “%temp%*” and “All Application” HIPS rule allows write to “Temporary Files”. That’s OK, but in our scenario doesn’t work since %temp% has wrong value.

This bug reduces rules flexibility.

It seems that user environment variables are hardcoded in configuration files. E.g. please consider fragment below (from default configuration):

		...
		<FileGroup UID="{D3B7E65E-3C95-44B0-81F6-EE0356BA9AEF}" Name="Temporary Files">
			<Files>
				<File Filename="%temp%\*" DeviceName="C:\Users\FooUser\AppData\Local\Temp\*"/>
				<File Filename="?:\$Recycle.Bin\*" DeviceName="?:\$Recycle.Bin\*" Condition="Os==Vista || Os==Win7"/>
				<File Filename="C:\Users\FooUser\AppData\Local\Microsoft\Windows\Temporary Internet Files\*" DeviceName="C:\Users\FooUser\AppData\Local\Microsoft\Windows\Temporary Internet Files\*"/>
			</Files>
		</FileGroup>
		...

Here %temp% user environment variable appears, but it’s hardlinked to “FooUser” - DeviceName=“C:\Users\FooUser\AppData\Local\Temp”. At the moment I don’t know does “DeviceName” part support environment variables, i.e. DeviceName=“%userprofile%\AppData\Local\Temp” would solve the issue.