Code Access Security - General Question

[Jeremy S.]

..NET's code Access Security enables administrators to restrict the types of
things that a .NET application can do on a local computer. For example, a
..NET Windows Forms application can be prevented from writing to the Registry
or writing a file to the local disk.

My question: Is this feature unique to .NET? Or is it just as easy for
enterprise network administrators to prevent COM applications from writing
to the Registry and doing local file I/O?

I'm basically wondering if .NET's code access security model is a "selling
point" to network administrators; something that would cause them to
generally favor the deployment of .NET Windows Forms applications over, say,
an "equivalent" VB6 (COM) application.

Thanks!

[Ralph]

"Jeremy S." <[e-mail]> wrote in message
news:OG**************@TK2MSFTNGP04.phx.gbl...

.NET's code Access Security enables administrators to restrict the types of things that a .NET application can do on a local computer. For example, a
.NET Windows Forms application can be prevented from writing to the Registry or writing a file to the local disk.

My question: Is this feature unique to .NET? Or is it just as easy for
enterprise network administrators to prevent COM applications from writing
to the Registry and doing local file I/O?

I'm basically wondering if .NET's code access security model is a "selling
point" to network administrators; something that would cause them to
generally favor the deployment of .NET Windows Forms applications over, say, an "equivalent" VB6 (COM) application.

Thanks!

No. This type of security is not unique to .Net.

This is a rather difficult question to answer because for years Windows
Security (Apps and OS) in general has received poor implementation. By that
I don't mean that Windows was inherently less secure than other
environments, only that the default essentially turned most security off,
and to invoke extra or higher security was a bit painful. Documentation was
often poor and slightly obscure. Most MS security (and admin) tools were
awkward, incomplete, and often came in multiple flavors which didn't
necessary work well together. For an example take some time to review the
history of Windows encryption libraries in.

So while it has always been possible to 'lock-down' a Windows app or COM,
many just didn't go there. Corporations or groups that needed 'extra'
security often went to 3rd party tools. Also, especially in the VB world,
but just as prevalent everywhere else, programmers themselves are pretty
naive when it comes to security. Until recently there were two common
beliefs. One, that 'security' was the App's job, or two, that 'security' was
the Admin's job. Adopting either model leaves some ugly holes.

Places where a consistent security model is adapted across the enterprise is
very rare. It is not uncommon to go into any organization and find 3 or 4
different 'security' models - depending on suite, the authors, or management
at the time.

With Windows XP sp2, MS finally got serious with security. Not only is laxed
security no longer the default, but the tools are better coordinated and
better documented. This new interest also extends to .Net. The 2.0 Framework
provides ready access to newer tools and a more consistent model. (Note .Net
1.x still required the developer to invoke system resources through pInvoke,
or 'extra' work.)

So while .Net is touted as being more 'Secure', it owes this increase to a
more secure OS and its more consistent, built-in security tools, not to
something particularly unique to .Net.

However, considering that something that is 'easier' to do is likely to be
used more often, and that securing COM is still not as simple as securing a
..Net app, then .NET would be easier for Admins to administer. BUT, the
organization still has to buy into a total security model.

-ralph