Hi,

Would it be possible to implement in DW a policy to run unknown or new application untrusted?

I have the impression there is still a potential threat for the system as not all programs are "watched". This measure would close this "gap".

Thanks for an answer

Yes, it is possible, but the most important thing is: how to do this the most non-irritating way?

Maybe the policy applies "by default". Any new app. runs untrusted. If it was not the intention of the user to run it untrusted, he will have to rollback, go to the exclusion list (that you have created for this purpose), in which you can add the concerned app., the updaters, compilers (for example, windows update could be by default on this list)... and god knows what.

In expert mode, maybe it would be done through a questionning window: "do you want to run this new app. trusted or untrunsted?".

This should also apply to scripts of course.

In order to be sure that it couldn't be too annoying or even mistaking for non tweakers, this policy should be turned off upon install. Only willing users, who wish increased security, would switch it on...

Hope it helps

I forgot to tell: Maybe you should modify yours rules of trust inheritance. Created processes do not inherite the trust from parent application. They are untrusted by default except told otherwise by the exclusion list or through the questionning window. Maybe I am a little bit naive on this subject. It looks much more simple than it actually is.

Hi again,

I was thinking about trust in DW. DW HIPS status can be seen through DW HIPS - File Prperties:

Status 1: Trusted or Untrusted (main status)
Status 2: Secured or Non-secured (read access status from untrusted source)
Status 3: Allowed or not allowed to be modified by untrusted

Maybe you could add a 4th status: trust inheritance allowed to children processes and scripts (whatever the status of the parent application, trust status is inherited), or not allowed (children processes and scripts run always untrusted). Except if rule is overridden by exclusion list input.

Thanks for any reply

I think downloaded applications via IE or FF are run as untrusted by default. Also, you can right-click on an executable file and select run as untrusted if you are suspicious of the file.

Yes.

I think you missed the point...

You can not run all processes untrusted, so there is a potential big hole in DW security.

How to deal with processes which run trusted and could be a gate to infection?

If we forget about buffer overflow exploitations or vulnerabilities ("exploits"), so a way to protect more fully the computer is maybe to apply a (lighter) policy on trusted processes (no inheritance of trust).

I don't if I'm right. Maybe Ilya will enlighten us...

Maybe, but I just miss the point. What the problem is?

I was trying to participate in the answer to this

Ah, I see. Well, there are, in fact, only one way- popup window with question, like GeSWall. Don't like this idea. New application runs untrusted- well, but what if I don't like this idea. And how to identify "new" - by path or by hash? Many questions- no answers (at least, for now).

But I'm thinking about it...

Shouldn't DW be installed on a clean machine to achieve this security without the hassles?

In fact- yes, in must be installed on clean computer.

Well, I mean that:
Upon install, you create a list of all programs on the computer. They are all trusted except the ones in the untrusted list. All the untrusted run untrusted and child processes run therefore untrusted.
At the moment, trusted progs run trusted as progs created by them. What I propose is to give option to change this rule. Then rule would become: trusted progs run trusted, BUT progs created by trusted processes (and maybe child processes) run by default UNTRUSTED. Identifying "new" seems now easy, because with a precise definition. Some problems could occur (I think that specific rules should be added to system progs or processes like svchost...). But all in all, security should be increased: Integrity of system is guaranteed, even from trusted processes.

What you are speaking of is 'white-listing'. This is really against the principles of DefenseWall. The security standpoint of DW is to be installed on a clean system and to keep it clean by preventing all sources of possible intrusion - even if your firewall lets something through, your browser has a security flaw not patched yet, you accidentally download something malicious, etc., you are always protected as long as your internet software is run as untrusted. There would be no benefit of having application white-listing built into DefenseWall, especially if you used the installer to auto-trust all existing software on your computer.

Possible sources of malware (USB Drives, CD-ROMS, Floppy Disks, Firewire, Internet, etc.)
|
DefenseWall (Browser, P2P, E-mail, Messaging, etc.)
|
Your Computer (This is one big white-list)

Any trusted applications that spawned other applications as untrusted would be a major problem for you. Almost all of the software on your computer spawns other files in order to work properly.

Certainly not. Anyway, I guess that on this particular point, Ilya is the one to precise the principles of DW.

Let me give an example. You have your list of untrusted processes and for whatever reason you forget to add a movie player (let's say divxplayer). You decide to surf the web, find a movie you wanna watch (.avi). You click on it and .avi are linked to divxplayer. you have a typical example of importing in your system (trusted) an untrusted material. Imagine now there is some code in it (bad one). The integrity of your system might be compromised... Well you might reply that I have to be carefull adding the proper proceses to the untrusted list.

Well, there are certainly other examples not so obvious (like system processes connecting to the web, program automatic updates...). One might say the solution of systematically untrusting new processes created by trusted sources is too much. It is only a proposition for the ones who want a fuller control of their system. (anyway, as already told, you can ut built-in rules for the sytem processes, configurable exception list for update programs...). And I guess you never need any window for any question. If something goes wrong (update impossible for example), you rollback, watch events, find the cause (update program which creates untrusted install program), add it to the exception list. That's it.

I therefore believe it is in the spectrum of DW. (anyway DW is a white list HIPS: have a look at the DW properties of a program)

Cheers

This all is out of white-list HIPS. I'm not sure people need such the huge, resource-hungry system. Also, I'm not really sure people will be able to work effectively with such the system every day (malware infection is quite rare situation, your job is every day one). Anyway, to start think about such the "from while-list" control, I need to finish with 2.0 version and, later on, implement all the features that will increase protective and easy-to-use capabilities of DW under current protective model.

Anything opened through an untrusted source would be tagged untrusted, so I don't see how the movie file would be an issue unless you downloaded it and didn't open it for a while. Maybe there could be added some sort of notification that at one point and time the movie file came from an untrusted source and prompt the user to keep it untrusted or not (this would be very rare and not be an often prompt).

If you where to run a software updater as untrusted, how would the update be successful?

Ilya, what do you think about adding a long-term tag to files downloaded through untrusted sources that prompts the user of the source? If you wanted to get even more detailed you could implement something similar to what Spyberus has and notify the user of the website it came from...

Well, first of all- not all the files tags as untrusted. .avi. for example, doesn't as Windows Media Player is untrusted by default. Also, I haven't heard about .txt-based malware... Yes, there could be buffer overflow-based issues, but it is not a DefenseWall's field of defense- Hardware DEP or DefencePlus just for it.

Who will really need to know the source of the executable file?

Just nice to know where Trojan.MessedYouUp came from.

Maybe you should add more extensions into the list.

If you are not going to continue development of DefencePlus, why recommend it? Does it cover all issues at hand already?

Right now, DefencePlus has more then enought functionality to protect from buffer overflow attacks. All the modern computers has a Hardware DEP.

You see, each protection conmonent has its own role. Hardware DEP for buffer overflow protection, DW for drive-to-download malware. Also, it is always possibe to "run as untrusted" any file.

For users without hardware DEP protection (people not as lucky as me and you), you should consider the possibility of things being auto-run through the browser or live streamed. Maybe running media files would help the users without effecting compatibility of DW. What do you think?

Not sure if I understand it right, but it is always possible to run anything as untrusted manually. Yes, it is possible to automatic tracking, I'm just not sure if it is really necessary.