Hi John,
Alchemi already does exactly that!
Run each Grid application in a seperate Application domain (on the
executor) created dynamically at runtime;
It has always done that, right from the beginning (It is not just
.Net2.0, even .Net 1.1 gives you good control over AppDomains.). This
way we already do have a simple sandbox on the executor, however
there is a need to enforce proper permissions on the sandbox. Currently
the appdomain created on each Executor gives the app full permissions.
This is actually where improvements need to be made.
Cheers
Krishna.
Jonathan Mitchem wrote:
John,
Do you have any references, books or web, that discuss .NET 2.0's
ability to use app domains in that manner?
Jonathan
On 2/21/06, John Sheppard <[EMAIL PROTECTED]> wrote:
Krishna,
Another approach you might want to look into is to run each grid app in
it's own appdomain and limit the abilities of that app domain. You can lock
it down to a specific directory if the executor service is dropping data
files to given directories for a grid app. You could lock out app domains
from using the System.Net namespaces there by limiting phone home abilities
and you can make the executor more resilent by allowing the offending app
domain to die upon an unhandled exception rather than bringing down the
executor. You could also take advantage of caching grid apps on the client
machine where you wouldn't have to push or sip that app if you already have
the dlls on your system. .NET 2.0 does a very good job of allowing you set
up Sandboxing environs using app domains.
John
On 2/21/06, Krishna < [EMAIL PROTECTED]> wrote:
Hi Jonathan,
I guess a simple way to prevent "grid-viruses", would be to use the .NEt
CAS (Code access security)
feature. We will need to implement some code in Alchemi to run user code
under reduced priveleges inside a sand-box kind of environment on
an Executor.
Cheers
Krishna.
Jonathan Mitchem wrote:
I've been thinking about security recently, and started questioning
the security of a distributed system such as Alchemi.
Is there anything that actually "constrains" the grid environment on a
machine so that a user doesn't allow some sort of distributed malware
to damage their machine?
For instance, an application that reads the files on the machine
hosting the Executor, searches for certain files or filetypes (like,
password and private key files), and then sends them to a specified
address. And maybe even proceeds to break their encryption.
Or, an application that creates several threads so that every machine
has a copy of the required DLLs, which subsequently proceeds to remove
critical system files from every machine.
Is there anything to prevent such sort of usage? And if not (since
I'm presuming there isn't), how would we go about preventing such
damage?
Jonathan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers
--
Life should NOT be a journey to the grave with the intention of arriving
safely in an attractive and well preserved body, but rather to skid in
sideways, paddle in one hand, beer in the other, body thoroughly used up,
totally worn out and screaming "WOO HOO what a ride!"
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers
alche
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
alchemi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-users
