"Scott McChesney" <scott.NO.SPAM.mcchesney@us.army.mil> wrote in message
news:O$132vlqFHA.2696@TK2MSFTNGP11.phx.gbl...
>I am in need of some guidance on an application I'm creating.  We have a
>series of nightly jobs that are run by a dedicated machine using the
>Windows Task Scheduler.  These jobs span several projects, and perform a
>number of different tasks.  I've been working on an application that will
>manage all of them via a pluggable architecture.  I'm doing some testing,
>and I've run into a problem.
>
> The idea behind the architecture is that I have created a base Job class
> that every job must inherit from.  However, these jobs can be in any
> assembly.  The job engine is provided configuration files that point to
> the assembly & class to use, along with some path information for assembly
> searching - job assemblies are loaded into a separate AppDomain so I can
> unload them when the engine is finished running them.
>
> The issue is that this application will eventually be running from a
> network drive.  Since that's the "LocalIntranet" zone, what I'm attempting
> to do isn't allowed.  After doing some research, it appeared that the
> solution was to sign my assemblies and create a custom code group for that
> signature. The problem I see is that there's nothing guaranteeing that any
> external assemblies containing jobs to run have been signed, much less
> with my particular key file.  The jobs may not be written by me, and I
> don't want to pass around my key file to anyone who might create a job for
> my app.
>
> Some investigation shows that there is an "Application Directory"
> condition, and I have no problem telling job writers they have to store
> their jobs in a subdirectory of my job application (which would seem to
> solve my problem, since I can grant "FullTrust" to the appropriate
> directory.)  But while I understand how to set up the child code group, I
> don't see how to associate it with my application out on the network.
>
> I am a newbie in this area, so I'm quickly getting lost here.  I can try
> to push for my application to be installed locally on the scheduling
> machine, but I don't think I can win that one.  Even if I do, I can still
> see potential problems loading an assembly from a network drive - a
> distinct possibility.
>
> Can anyone shed some light on my situation?  What's the best/preferred
> method of handling this?  Or am I just heading down the wrong road, and
> need to re-think things?
>
> Any help would be *greatly* appreciated.  Thanks!
>
> - Scott
>

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:%23vD8m4wqFHA.2648@TK2MSFTNGP10.phx.gbl...
> What you're proposing to do is actually rather dangerous.  Since you don't
> know the origin of the plug-in assemblies, why are you so prepared to
> "vouch" for their trustworthiness?  Instead of trying to ensure that the
> plug-in assemblies are granted full trust, why not simply let them fail if
> they don't have the permissions they need to do their work?  If you
> provide adequate details in your error messages, the application
> administrator would presumably be well equipped to make an informed
> decision about whether the target assembly is sufficiently trustworthy to
> merit the permissions it needs and then modify policy as necessary to
> assign those permissions.
>
>
>
> "Scott McChesney" <scott.NO.SPAM.mcchesney@us.army.mil> wrote in message
> news:O$132vlqFHA.2696@TK2MSFTNGP11.phx.gbl...
>>I am in need of some guidance on an application I'm creating.  We have a
>>series of nightly jobs that are run by a dedicated machine using the
>>Windows Task Scheduler.  These jobs span several projects, and perform a
>>number of different tasks.  I've been working on an application that will
>>manage all of them via a pluggable architecture.  I'm doing some testing,
>>and I've run into a problem.
>>
>> The idea behind the architecture is that I have created a base Job class
>> that every job must inherit from.  However, these jobs can be in any
>> assembly.  The job engine is provided configuration files that point to
>> the assembly & class to use, along with some path information for
>> assembly searching - job assemblies are loaded into a separate AppDomain
>> so I can unload them when the engine is finished running them.
>>
>> The issue is that this application will eventually be running from a
>> network drive.  Since that's the "LocalIntranet" zone, what I'm
>> attempting to do isn't allowed.  After doing some research, it appeared
>> that the solution was to sign my assemblies and create a custom code
>> group for that signature. The problem I see is that there's nothing
>> guaranteeing that any external assemblies containing jobs to run have
>> been signed, much less with my particular key file.  The jobs may not be
>> written by me, and I don't want to pass around my key file to anyone who
>> might create a job for my app.
>>
>> Some investigation shows that there is an "Application Directory"
>> condition, and I have no problem telling job writers they have to store
>> their jobs in a subdirectory of my job application (which would seem to
>> solve my problem, since I can grant "FullTrust" to the appropriate
>> directory.)  But while I understand how to set up the child code group, I
>> don't see how to associate it with my application out on the network.
>>
>> I am a newbie in this area, so I'm quickly getting lost here.  I can try
>> to push for my application to be installed locally on the scheduling
>> machine, but I don't think I can win that one.  Even if I do, I can still
>> see potential problems loading an assembly from a network drive - a
>> distinct possibility.
>>
>> Can anyone shed some light on my situation?  What's the best/preferred
>> method of handling this?  Or am I just heading down the wrong road, and
>> need to re-think things?
>>
>> Any help would be *greatly* appreciated.  Thanks!
>>
>> - Scott
>>
>
>

> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:%23vD8m4wqFHA.2648@TK2MSFTNGP10.phx.gbl...
>> What you're proposing to do is actually rather dangerous.  Since you
>> don't know the origin of the plug-in assemblies, why are you so prepared
>> to "vouch" for their trustworthiness?  Instead of trying to ensure that
>> the plug-in assemblies are granted full trust, why not simply let them
>> fail if they don't have the permissions they need to do their work?  If
>> you provide adequate details in your error messages, the application
>> administrator would presumably be well equipped to make an informed
>> decision about whether the target assembly is sufficiently trustworthy to
>> merit the permissions it needs and then modify policy as necessary to
>> assign those permissions.
>>
>>
>>
>> "Scott McChesney" <scott.NO.SPAM.mcchesney@us.army.mil> wrote in message
>> news:O$132vlqFHA.2696@TK2MSFTNGP11.phx.gbl...
>>>I am in need of some guidance on an application I'm creating.  We have a
>>>series of nightly jobs that are run by a dedicated machine using the
>>>Windows Task Scheduler.  These jobs span several projects, and perform a
>>>number of different tasks.  I've been working on an application that will
>>>manage all of them via a pluggable architecture.  I'm doing some testing,
>>>and I've run into a problem.
>>>
>>> The idea behind the architecture is that I have created a base Job class
>>> that every job must inherit from.  However, these jobs can be in any
>>> assembly.  The job engine is provided configuration files that point to
>>> the assembly & class to use, along with some path information for
>>> assembly searching - job assemblies are loaded into a separate AppDomain
>>> so I can unload them when the engine is finished running them.
>>>
>>> The issue is that this application will eventually be running from a
>>> network drive.  Since that's the "LocalIntranet" zone, what I'm
>>> attempting to do isn't allowed.  After doing some research, it appeared
>>> that the solution was to sign my assemblies and create a custom code
>>> group for that signature. The problem I see is that there's nothing
>>> guaranteeing that any external assemblies containing jobs to run have
>>> been signed, much less with my particular key file.  The jobs may not be
>>> written by me, and I don't want to pass around my key file to anyone who
>>> might create a job for my app.
>>>
>>> Some investigation shows that there is an "Application Directory"
>>> condition, and I have no problem telling job writers they have to store
>>> their jobs in a subdirectory of my job application (which would seem to
>>> solve my problem, since I can grant "FullTrust" to the appropriate
>>> directory.)  But while I understand how to set up the child code group,
>>> I don't see how to associate it with my application out on the network.
>>>
>>> I am a newbie in this area, so I'm quickly getting lost here.  I can try
>>> to push for my application to be installed locally on the scheduling
>>> machine, but I don't think I can win that one.  Even if I do, I can
>>> still see potential problems loading an assembly from a network drive -
>>> a distinct possibility.
>>>
>>> Can anyone shed some light on my situation?  What's the best/preferred
>>> method of handling this?  Or am I just heading down the wrong road, and
>>> need to re-think things?
>>>
>>> Any help would be *greatly* appreciated.  Thanks!
>>>
>>> - Scott
>>>
>>
>>
>
>

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:utnawuIrFHA.3068@TK2MSFTNGP14.phx.gbl...
> "Scott McChesney" <tm***@N.O.S.P.A.M.netins.net> wrote in message
> news:%23WMrwW$qFHA.2596@TK2MSFTNGP09.phx.gbl...
>> It's not a question of the trustworthiness of the job plug-in's - it's
>> the trustworthiness of my job engine code.  The design I'm working on
>> uses reflection and secondary AppDomains to do its job.  Those operations
>> are not allowed by default from the "LocalIntranet" zone, and my code
>> will be running from a network drive.  It's those operations that I need
>> to allow, but I don't want to change the default "LocalIntranet"
>> settings - I only want to allow it for my application.
>
> Your first message in this thread seemed to indicate that you know how to
> grant these additional permissions for your own assemblies (i.e.: add a
> code group based on your assemblies' evidence to the LocalIntranet group
> in the client machine CAS policy).  Is there some specific help you would
> like with this approach?

"Scott McChesney" <scott.NO.SPAM.mcchesney@us.army.mil> wrote in message
news:%23MtnNxJrFHA.2996@tk2msftngp13.phx.gbl...
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:utnawuIrFHA.3068@TK2MSFTNGP14.phx.gbl...
>> "Scott McChesney" <tm***@N.O.S.P.A.M.netins.net> wrote in message
>> news:%23WMrwW$qFHA.2596@TK2MSFTNGP09.phx.gbl...
>>> It's not a question of the trustworthiness of the job plug-in's - it's
>>> the trustworthiness of my job engine code.  The design I'm working on
>>> uses reflection and secondary AppDomains to do its job.  Those
>>> operations are not allowed by default from the "LocalIntranet" zone, and
>>> my code will be running from a network drive.  It's those operations
>>> that I need to allow, but I don't want to change the default
>>> "LocalIntranet" settings - I only want to allow it for my application.
>>
>> Your first message in this thread seemed to indicate that you know how to
>> grant these additional permissions for your own assemblies (i.e.: add a
>> code group based on your assemblies' evidence to the LocalIntranet group
>> in the client machine CAS policy).  Is there some specific help you would
>> like with this approach?
>
> Yes - this is what I need the help with.  What I'd prefer to do is create
> a custom code group of "LocalIntranet" using the "Application Directory"
> setup.  Then, I can provide the appropriate reflection/AppDomain
> privileges to that group only.  My problem is that I don't know how to
> associate my application with the custom code group...
>
> - Scott
>

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:eZ$vcMWrFHA.4044@TK2MSFTNGP09.phx.gbl...
> In order to minimize the risk of inappropriate elevation of privilege via
> your new code group, it would probably be best to be as specific as
> possible in its membership condition.  You've already mentioned three
> candidate criteria for membership:
>
> 1.  Running from the intranet zone,
> 2.  Running from a particular folder on the network, and
> 3.  Signed with your strong naming key.
>
> I would suggest that you structure your code group additions to only
> elevate the permissions of code that meets all three of the above
> conditions.  Here are the steps for manually applying the simplest-case
> policy modifications on a machine that needs to run your application:
>
> 1.  Launch mscorcfg.msc as an admin user.  (It may be listed as "Microsoft
> .NET Framework <version> Configuration" under the "Administrative Tools"
> listing on your start menu.)
>
> 2.  Expand the Runtime Security Policy\Machine node.  (All nodes touched
> in subsequent steps will be children of this nods.)
>
> 3.  Expand the Permission Sets node.
>
> 4.  Add a new permission set that includes the additional permissions that
> your application needs when running from the intranet zone.
>
> 5.  Expand the Code Groups\All_Code\LocalIntranet_Zone node.
>
> 6.  Add a new code group to the LocalIntranet_Zone group with the
> following configuration:
>    a.  Membership condition: URL corresponding to the shared folder path
> from which your application will be run (e.g.:
> file://SomeShare/SomeFolder/*).
>    b.  Permission set: Nothing
>
> 7.  Add a new code group to the group created at step 6 with the following
> configuration:
>    a.  Membership condition: Strong name match on the public key with
> which your application assemblies are signed.
>    b.  Permission set: The permission set created at step 4.
>
> With the above configuration, any assembly that is loaded from the
> application shared folder in the intranet zone and is signed with your
> strong name key should receive the additional permissions.  Any assembly
> that does not meet all three criteria should not receive the addition
> permissions.  Make sense?
>
>
>
>
>
> "Scott McChesney" <scott.NO.SPAM.mcchesney@us.army.mil> wrote in message
> news:%23MtnNxJrFHA.2996@tk2msftngp13.phx.gbl...
>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
>> news:utnawuIrFHA.3068@TK2MSFTNGP14.phx.gbl...
>>> "Scott McChesney" <tm***@N.O.S.P.A.M.netins.net> wrote in message
>>> news:%23WMrwW$qFHA.2596@TK2MSFTNGP09.phx.gbl...
>>>> It's not a question of the trustworthiness of the job plug-in's - it's
>>>> the trustworthiness of my job engine code.  The design I'm working on
>>>> uses reflection and secondary AppDomains to do its job.  Those
>>>> operations are not allowed by default from the "LocalIntranet" zone,
>>>> and my code will be running from a network drive.  It's those
>>>> operations that I need to allow, but I don't want to change the default
>>>> "LocalIntranet" settings - I only want to allow it for my application.
>>>
>>> Your first message in this thread seemed to indicate that you know how
>>> to grant these additional permissions for your own assemblies (i.e.: add
>>> a code group based on your assemblies' evidence to the LocalIntranet
>>> group in the client machine CAS policy).  Is there some specific help
>>> you would like with this approach?
>>
>> Yes - this is what I need the help with.  What I'd prefer to do is create
>> a custom code group of "LocalIntranet" using the "Application Directory"
>> setup.  Then, I can provide the appropriate reflection/AppDomain
>> privileges to that group only.  My problem is that I don't know how to
>> associate my application with the custom code group...
>>
>> - Scott
>>
>
>