Trusted Files, still sandboxed everytime


I am trying to automount some of my truecrypt volumes. But when I try to do it with Pstart, it always sandboxes pstart and truecrypt.

I tried to add them to trusted files, but they are already showing up as trusted in the list.

What should I do?

[attachment deleted by admin]

Hey Siva

I hope the tip below will help.

Add them here CIS —> Defense+ —> Defense+ Settings —> Execution control Settings —> Detect shellcode injections (i.e. Buffer overflow protection) —> Exclusions —> Add —> Browse…

Valentin N

You must use Installer or Updater Policy: go to Defense+ → Computer Security Policy → Add → browse to the file(s) you want to prevent sandboxing and Use a Predefined Policy: Installer or Updater → Apply.

I will do as you suggested and tell you the result, but

Let me explain it in detail…

I am facing this problem on all the PCs I have installed CIS on. My friends PCs, my home PCs and all.

I have all my portable applications on my pendrive locked with truecrypt and I run them using pstart. So, every time I connect my pendrive to a system, I click on Pstart.exe, start truecrypt and mount my volume(which is on pendrive itself), it is password protected.

My scheme works fine on all systems, but with CIS I currently have to disable Sandbox to work it out.

Your suggestions may solve it on my office PC (temporarily), the drive letter of my pendrive would not be the same every time I connect it to PC, and I may not be able to do all this on all the systems. That is why I am more interested to know as to what reason both these programs are being sandboxed every time although they are trusted.

Please… I need to know the concept (rather than)/(along with) the workarounds so that I can have a permanent solution to my issue.

External storage is always going to be considered untrusted. You can not trust or exclude applications run from external media. This is by design.

So, Is disabling sandbox on every system, where ever CIS is installed, the only solution for me?

A trusted program from external storage is still untrusted…

Sounds weird…

You could always transfer the files from your pendrive to your local HD. (Yes, I’m aware this is less than convenient, but I’ll take safety over convenience any day…)

Not really.

As an example, would you prefer to receive an infected pendrive from a friend that uses the same method of file access, and since you’ve trusted the starter application, your friends drive happily infects your system? (Yes, this is a bit of a general example that doesn’t exactly apply to your situation because you’ve passworded TrueCrypt, but I think you’ll understand the concept)

I agree safety is more important, but usability is also of concern too…

There should be some balance… at some level…

May be we can allow a trusted file to run, still leaving it’s child processes untrusted (Just my idea).

As in my case, truecrypt is in itself fully trusted and never malicious as is the case with pstart. The problem that you are telling is that after CIS allowing either pstart or truecrypt to run in the real machine(not in sandbox), it can then initiate some other process which may be malicious. In such a case, can’t we impose sandbox settings on the sub/child process started by the trusted application (truecrypt or pstart in my case), while still allowing truecrypt…

I am just proposing this… I do not know whether this can be easily implemented or not…

Still, Does it not look weird to close our doors even to our own family members/friends, though we know that they are our family/friends, just because they are knocking the door from outside…

May be we need to rethink about this design policy…

Maybe a solution would be if Sandbox keep the name of the allowed file, the location, and also a hash value of it, so it can recognise if it has been infected?

How does CIS remember/identify a trusted application ? by path or by hash ?

If it is by path…what you said is true.

If it uses hash to identify a trusted application, there would be no problem even if it resides on an external drive…Because, if it really gets infected somewhere, the hash of the file would change…

If I build an .exe and trust it, then recompile the .exe, CIS no longer recognizes this application. This would indicate file hash to me.

Then, what is the problem if the .exe resides locally or externally…

If it gets infected when connected to another PC, it’s hash would change any way…

It has the same hash, means it is clean, so we can allow it to run, even it is from an external drive…

am I missing something here ?

Encrypted partitions are not seen as safe by CIS like it does not trust external devices like USB drives and USB flash drives either.

That’s my point…

If trusting is done by calculating hashes, the present policy of “Always untrust External drives” becomes meaningless…

Untrusted External Devices trumps hash check.

I’m terribly sorry, but trusted program can be considered trusted only if CRC and signature is correct - aren’t it? So what difference makes the nature of media from which particular file is starting?

External media can not be continuously monitored by CIS and are therefor not considered safe.

Programs marked in computer security policy as installer/updater are trusted even if the file is changed to a new version. It relied on CIS continuously monitoring the files. The current trusted files list that uses a hash did not exist.

Now users can add files to trusted files and not have them in computer security policy CIS could be changed so files on removable drives are trusted if they are in the trusted files list.

I cannot confirm this. I have firefox.exe as trusted file and changed it with the latest nightly build. The nightly build got sandboxed.

I am on v 5.8 beta 2. Can you tell me how you tested your finding? What happens when you do my test?

Now users can add files to trusted files and not have them in computer security policy CIS could be changed
I am not sure what you are trying to say here. Could you rephrase?
so files on removable drives are trusted if they are in the trusted files list.
I tested that and indeed files on external media get trusted when they are in Trusted Files.

I did some more testing. I copied the .bat file that I use from the USB drive to Desktop and the file would start up without getting sandboxed. When I removed the file from Trusted Files it was no longer recognised when starting it from USB drive or Desktop.

Conclusion is that hash recognition trumps the fact that a file is on an external medium.

In old (V3?) versions of defence+ everything went into computer security policy and once it was there the rules always worked even if the program was updated to a new version. The developers said it did not use a hash and relied on defence plus monitoring and preventing changes to programs by malware. This made it dangerous to trust files on removable drives.

Now there is no need to have all your programs in computer security policy. If you have “create rules for safe applications” unticked no rules are automatically created. Instead, all the programs get added to trusted files. This does appear to use a hash. If you update an unsigned program you have to add it to trusted files again. Signed programs get added automatically and multiple entries appear for the same program when it is updated.

If trusted files is used but “create rules for safe applications” is not ticked it should be safe to trust files on removable media. If they get changed the hash will not match and it will not be trusted and no rules will be saved in computer security policy.

The developers could allow programs on removable drives to be trusted but I don’t know if they have. I was guess not from this thread. I don’t run programs from removable drives (I have applocker preventing it) so I can’t easily test this myself.