CAS? When to use it

[Chad Myers]

Before I spend a lot of time reading about something
I might not need to use/worry about, can someone give me
the 5 second take on CAS?

In general, when do I need to worry about it (what type of
apps in what types of environments)?

I'm writing a data access API for a proprietary system. We're
shipping this API to customers who build apps on top of this
API/foundation library.

What, if anything, should I be thinking about in terms of CAS?

Thanks,
Chad

 

[Joe Mayo]

Hi Chad,

Take a look at your component's public interface to see what other code has
access to. There is something called a Luring attack where calling code
tries to get your code to do something on its behalf. If such potential
exists, you'll want to protect your code so that Administrators or a setup
program operating on the Administrator's behalf can set up appropriate
policy. Here's an article I wrote on CAS Policy:

http://www.code-magazine.com/Article.aspx?quickid=0405031

As you probably know, there is much more in the MSDN Security Developer
Center:

http://msdn.microsoft.com/security/

Joe

 

[Joe Mayo]

Sorry to reply to my own post, but I had second thoughts about something in
the meantime. This was a simplified description that doesn't truly do
justice in the way of properly implementing security. The right thing to do
is to learn about how CAS works, and learn about how to do proper Threat
Modelling. Any shortcuts to get from point A to point B are better than
nothing, but you shouldn't have a false sense of security and you should
understand that your code could still be vulnerable.

Joe

 

[Richard Blewett [DevelopMentor]]

As with all security the issue is are you guarding a resource that requires protection? In you r cas it sounds as if you are.

So the next question is do I need to base this protection on *which principal (user)* is making the call? If so then windows/ACL based security comes in to play.

The next question is: does it matter which code calls your functionality directly or indirectly? In other words is there an issue with code of unknown origin accessing the resource just because it happens to be running with a certain user's credentials? If so, then CAS comes in to play.

CAS is an article (or several) to explain so i won't do it here. But if you have sepcific questions I'm sure we'll all try to answer them

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Sorry to reply to my own post, but I had second thoughts about something in
the meantime. This was a simplified description that doesn't truly do
justice in the way of properly implementing security. The right thing to do
is to learn about how CAS works, and learn about how to do proper Threat
Modelling. Any shortcuts to get from point A to point B are better than
nothing, but you shouldn't have a false sense of security and you should
understand that your code could still be vulnerable.

Joe

Hi Chad,

Take a look at your component's public interface to see what other code has
access to. There is something called a Luring attack where calling code
tries to get your code to do something on its behalf. If such potential
exists, you'll want to protect your code so that Administrators or a setup
program operating on the Administrator's behalf can set up appropriate
policy. Here's an article I wrote on CAS Policy:

http://www.code-magazine.com/Article.aspx?quickid=0405031

As you probably know, there is much more in the MSDN Security Developer
Center:

http://msdn.microsoft.com/security/

Joe

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.languages.csharp]

 

[Leon Lambert]

Well, following are some comments from a dis-illusioned developer. We
had meeting with Microsoft last week dealing with topics nearly the same
as the one you are asking about. One of the attendees was a person on
the actual CLR team so he should know what he is talking about. One of
the aspects of CAS we wanted to get detailed about was protecting some
of our dlls from having the customer calling them. Things dealing with
passwords and account setups. We need it as a dll because we have a
suite of applications and they need to share the same code. Basically
the CLR guy told us that there was no way to protect our dlls if they
are installed on the customer machine and he has Administrator
privleges. A determined person could work around any CAS features we
would try to implement. Licensing was really the best way to do the
protection he said. CAS was basically designed to protect the owner of a
machine from external code being accessed not to protect from code
installed on the machine.

This knowledge really floored us. We are having to rethink our design.
Protecting some sub-components are a must for us. At this point we don't
know how to approach it. Might have to go back to good old C++ and the
old fasion ways of doing this protection. Sad, was hoping to relegate
C++ to lower level funtions like drivers.

Sorry if this disillusions you about CAS but that is the state i am in
right now.
Leon Lambert

 

[Richard Blewett [DevelopMentor]]

This is really an issue about communication. I don't think the purpose of CAS has been communicated by Microsoft very well over the years. People hear thats its the .NET security model and assume its all-encompasing, rather than one tool in a suite that wee need to secure our applications and machines from unwanted access. CAS is great because it gives us a tool we didn't have before but its not designed for the purpose you needed.

A|lthough I must admit, I'm not sure how going to C++ is going to help (or hinder for that matter)

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Well, following are some comments from a dis-illusioned developer. We
had meeting with Microsoft last week dealing with topics nearly the same
as the one you are asking about. One of the attendees was a person on
the actual CLR team so he should know what he is talking about. One of
the aspects of CAS we wanted to get detailed about was protecting some
of our dlls from having the customer calling them. Things dealing with
passwords and account setups. We need it as a dll because we have a
suite of applications and they need to share the same code. Basically
the CLR guy told us that there was no way to protect our dlls if they
are installed on the customer machine and he has Administrator
privleges. A determined person could work around any CAS features we
would try to implement. Licensing was really the best way to do the
protection he said. CAS was basically designed to protect the owner of a
machine from external code being accessed not to protect from code
installed on the machine.

This knowledge really floored us. We are having to rethink our design.
Protecting some sub-components are a must for us. At this point we don't
know how to approach it. Might have to go back to good old C++ and the
old fasion ways of doing this protection. Sad, was hoping to relegate
C++ to lower level funtions like drivers.

Sorry if this disillusions you about CAS but that is the state i am in
right now.
Leon Lambert

Before I spend a lot of time reading about something
I might not need to use/worry about, can someone give me
the 5 second take on CAS?

In general, when do I need to worry about it (what type of
apps in what types of environments)?

I'm writing a data access API for a proprietary system. We're
shipping this API to customers who build apps on top of this
API/foundation library.

What, if anything, should I be thinking about in terms of CAS?

Thanks,
Chad

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.languages.csharp]

 

[Robert Jordan]

Well, following are some comments from a dis-illusioned developer. We
had meeting with Microsoft last week dealing with topics nearly the same
as the one you are asking about. One of the attendees was a person on
the actual CLR team so he should know what he is talking about. One of
the aspects of CAS we wanted to get detailed about was protecting some
of our dlls from having the customer calling them. Things dealing with
passwords and account setups. We need it as a dll because we have a
suite of applications and they need to share the same code. Basically
the CLR guy told us that there was no way to protect our dlls if they
are installed on the customer machine and he has Administrator
privleges. A determined person could work around any CAS features we
would try to implement. Licensing was really the best way to do the
protection he said. CAS was basically designed to protect the owner of a
machine from external code being accessed not to protect from code
installed on the machine.

This knowledge really floored us. We are having to rethink our design.
Protecting some sub-components are a must for us. At this point we don't
know how to approach it. Might have to go back to good old C++ and the
old fasion ways of doing this protection. Sad, was hoping to relegate
C++ to lower level funtions like drivers.

I'm sorry to bother you with that, but a little bit of CS
knowledge never hurts ;-) MS *knows* that you cannot build
a system that would help you to hide/restrict code on
user's machine. It's a proven problem, so just *forget*
about it.

Sorry if this disillusions you about CAS but that is the state i am in
right now.

It's in the state it *has* to be: to protect *users* from
hostile and/or dumb developers.

bye
Rob

 

[Chad Myers]

Joe Mayo and Richard Blewett, thank so much for your great replies!

I'm not so sure I need CAS. The API I'm developing is simply a data
access layer that allows other applications easy access to some basic
application services like cross-database data access, configuration,
logging, caching, etc.

It's basically a glorified SqlClient, ConfigurationSettings, and
log4net combination.

None of those components/classes/etc have CAS that I'm aware of. They
are enabling technologies rather than destinations.

It sounds like apps built ON TOP OF my library need to worry about CAS
because they're responsible for who has access to this resource
(database, primarily).

Most of the apps built using our foundation library will be web apps
which will use ASP.NET's authentication mechanism and I don't think
there's any chance for outside code to be introduced.

In light of this, do you think I need to worry about CAS? It sounds
like I don't. If SqlClient, DataSet/DataTable/DataRow and the like
don't use CAS, then I'm basically in the same boat and I don't have
to either, right?

Thanks again!

Sincerely,
Chad

As with all security the issue is are you guarding a resource that

requires protection? In you r cas it sounds as if you are.

So the next question is do I need to base this protection on *which

principal (user)* is making the call? If so then windows/ACL based security
comes in to play.

The next question is: does it matter which code calls your functionality

directly or indirectly? In other words is there an issue with code of
unknown origin accessing the resource just because it happens to be running
with a certain user's credentials? If so, then CAS comes in to play.

CAS is an article (or several) to explain so i won't do it here. But if

you have sepcific questions I'm sure we'll all try to answer them

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

Sorry to reply to my own post, but I had second thoughts about something in
the meantime. This was a simplified description that doesn't truly do
justice in the way of properly implementing security. The right thing to do
is to learn about how CAS works, and learn about how to do proper Threat
Modelling. Any shortcuts to get from point A to point B are better than
nothing, but you shouldn't have a false sense of security and you should
understand that your code could still be vulnerable.

Joe

Hi Chad,

Take a look at your component's public interface to see what other code has
access to. There is something called a Luring attack where calling code
tries to get your code to do something on its behalf. If such potential
exists, you'll want to protect your code so that Administrators or a setup
program operating on the Administrator's behalf can set up appropriate
policy. Here's an article I wrote on CAS Policy:

http://www.code-magazine.com/Article.aspx?quickid=0405031

As you probably know, there is much more in the MSDN Security Developer
Center:

http://msdn.microsoft.com/security/

Joe

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.languages.csharp]