a full set of access permissions, including restrictions on the ability to execute other programs
a limited set of protection, excluding restrictions on the ability to be executed by other programs
So to prevent a program being executed using HIPS rules you need to work out what might execute it, and block it from execution in that program’s rule. Normally it would be explorer.exe.
Or, much simpler, add it to blocked files.
AFAIK HIPS has worked this way since v3 of CIS. I used HIPS in that version and remember thinking it was counter intuitive at the time, but it has never changed. I think it may be to avoid conflicting rules.
If a past version did block a particular files under these circumstances it was probably because the other HIPS restrictions meant that it was prevented from doing something else it required in order to execute successfully.
Just to check what you are saying, in case I am misunderstanding, is the file on the HIPS blocked files list? (By that I mean in Advanced settings ~ Defence + ~ HIPS ~ Protected Objects ~ Blocked Files).
What are the ‘several points’?
I would be grateful if you could append screen-shots of all relevant settings in the rule you are creating.
I am still speaking about the rule set that has all set as blocked (isolated rule).
Drives, memory between processes (svchost+player), ram, screen… would be points that obviously have been “accessed”. Even though the setting is “block” for those. Probably keyboard (dont know if mediaplayer has shortcut keybinds)
I am really surprised if that actually wasnt covered by a “treat as “blocked”” rule.
OK so to clarify, you are not saying the file should be blocked from execution, you are saying it should not be allowed to do anything?
The objects you list are in general blocked for direct access, that is access which does not go via the normal high level Windows interfaces. Disk was instead blocked most accesses in 6.x, but is is debatable whether this was intended, so it may have reverted.
From what you are saying some actions are being blocked, some are not (presumably because they are not direct accesses). So it sounds to me that the behavior is as intended.
The isolated policy is designed to allow programs to run but not to do anything risky at all. Some programs won’t run under these settings - they crash or freeze, but some will.
Its identical as isolated. All set to be blocked. Just made to have a name that people can click in a question window.
This might be a rare case, so normally it doesnt confuse people (“the movie works!” ).
But i still think, it should not have been able to get a file from a drive, run under another process, being in ram… while such a ruleset is activated for it.
Additionally its not userfriendly if you want to try to get something blocked like the firewall would block, but for defense you have to go to settings and put it into a list that is hidden under PROTECTED files… who would find that there?
We cross posted, please see my reply above. Please also note that you can block execution in HIPS rules by changiong the rule of the executing process. But of course you need to change rules for svchost with care.
I know how to circumvent the problem for myself now.
It should be accessable from the question window though.
If you think thats ok behaviour of the program in this case, you can move this to setup configuration section.
I am fine with the behaviour if it only happens with windows mediaplayer.
BUT remaining questions:
Disc access doesnt mean "taking things from the drive?
And ram access isnt when something runs in it?
Memory between processes is not necessary to run under a process?
For object (keyboard,disk, RAM, screen) access, ‘direct’ means ‘other than via standard high level interfaces’. Disk access was an exception in version 6 - I have not tested in 7.
So for example access to another programs RAM by reading the bits and byte at an absolute memory location instead of asking for data from the program via standard interfaces (eg COM). COM can be otherwise restricted (protected COM objects).
Another example directly reading the bits that make up the screen image instead of asking for the value of data item in a Window controlled by the same program.
To execute a program from another program you call a specific high level OS interface.
The behavior I have described applies to all programs.
).