Security for a pluggable application

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Scott McChesney - 26 Aug 2005 17:33 GMT

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

Reply to this Message

Nicole Calinoiu - 27 Aug 2005 14:49 GMT

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.

>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
[quoted text clipped - 40 lines]
>
> - Scott

Reply to this Message

Scott McChesney - 28 Aug 2005 18:27 GMT

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.

The trustworthiness of the job plug-in's is being handled through a
different process...

- Scott

> 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
[quoted text clipped - 51 lines]
>>
>> - Scott

Reply to this Message

Nicole Calinoiu - 29 Aug 2005 12:20 GMT

> 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
[quoted text clipped - 3 lines]
> 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?

> The trustworthiness of the job plug-in's is being handled through a
> different process...

Then why are you concerned that the plug-in assemblies wouldn't be granted
additional permissions under a code group that uses your assemblies'
evidence for its membership condition? (Or have I missed the point, and
you're not actually worried about this at all?)

>> 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
[quoted text clipped - 51 lines]
>>>
>>> - Scott

Reply to this Message

Scott McChesney - 29 Aug 2005 14:19 GMT

>> 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
[quoted text clipped - 9 lines]
> 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

Reply to this Message

Nicole Calinoiu - 30 Aug 2005 14:02 GMT

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?

>>> 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
[quoted text clipped - 17 lines]
>
> - Scott

Reply to this Message

Scott McChesney - 30 Aug 2005 14:31 GMT

OK... I think I understand what you're creating. Under this situation, my
job engine code (that I sign with my key) will have the appropriate
additional permissions, but job assemblies not signed by my key will not get
the additional reflection/AppDomain privileges.

Thanks a ton for your help!

- Scott

> 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
[quoted text clipped - 64 lines]
>>
>> - Scott

Reply to this Message

Security for a pluggable application

Free Magazines