Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Why can I run unsafe code?

The Delphi for .Net compiler will let you do pointer arithmetic that results in unsafe code, code that fails peverify. (I assume C++ will do the same.) Yet, I can run this code locally, and it acts as it would on an unmanaged system.

I thought the JITter was supposed to raise an exception if it encountered unsafe code? Could someone point me to 1) a nice overview of the .Net security model (I'm afraid I find the "System.Security Namespace" dox a bit too ... holographic) and 2) a quick summary of how I tell my (XP Pro) machine to be a bit more paranoid?

Jon Shemitz
Friday, November 22, 2002

You want to take a look at caspol.exe.  From there I'd try google and msdn.

Sorry for not providing more explicit help but this tool has a lot of knobs and levers, I don't think a quick news group post can do it justice.

Steve Steiner
Friday, November 22, 2002

Basic concepts: code can be a member of one or more code groups. Membership depends on evidence, which are things that the CLR can determine about code. Each code group has a permission set assigned to it. A permission set is made up of multiple permissions.

Code groups are organized into three levels: enterprise, machine, user. (There's a fourth level, AppDomain, that can only be worked with in code itself). The permissions of an assembly at each level are the union of the permissions of each code group to which the assembly belongs at that level. The overall permissions of the assembly are the intersection of the permissions of the three levels for that assembly.

You can view all these bits and pieces in the .NET Framework Configuration Tool. (Start, Programs, Administrative Tools). If you do, you'll find that by default:

- The only code group at the enterprise level is All Code, whose membership condition is "All Code" -- that is, it applies to any assembly. The associated permission set is Full Trust. The FulL Trust permission set encompasses all possible permissions, including the permission to skip verification for type safety.

- The Machine level has a My_Computer_Zone code group, which includes all code that originates on your computer. This group also has Full Trust permissions. That gives code from your computer Full Trust at the Machine level, regardless of its membership in any other groups, because of the additive nature of permissions on a level.

- The User level also has an All Code group with FullTrust permissions.

Net effect: code originating on your computer has FullTrust (the intersection of FullTrust, FullTrust, and FullTrust) permissions, including permission to skip verification.

The easiest way to tighten this up across the board would be to take the My_Computer_Zone group and assign it a permission set that does not allow skipping verification. There's a named permission set Everything that should suit.

I've left out some of the finer points here. Take a look at the .NET Framework SDK/Programming with the .NET Framework/Securing Applications/Security Policy Management book in help for more.

Mike Gunderloy
Friday, November 22, 2002

Thanks, Mike. I'm left wondering, though, WHY does code get Full Trust by default? Seems to break the idea of managed code if you have to change the defaults to enable verification.

Jon Shemitz
Friday, November 22, 2002

Without any internal knowledge, I'd guess that they did not want to break the model of being able to write and run any code you like on your own development machine. Note that code from off-machine -- even from network shares -- has a lower level of permissions.

Mike Gunderloy
Friday, November 22, 2002

Good questions.  Mike's answers are right on the mark. 

1) Fully trusted code is granted "skip verification".  As a performance enhancement, the jitter skips verification on any code granted that right.

2) Security and usability are almost always at odds with each other. The decision to make "installed on local machine" equal to "full trust" is to avoid the maintenance nightmare of having to explicitly grant full trust to every piece of code you install on your machine.

Future releases of the CLR will almost certainly tweak the default policy to be something more secure without breaking too many scenarios.  For example, it might make sense to grant full trust only to the operating system directory and the Program Files directory, and grant Intranet-level trust to the rest.  But this is all still under discussion -- if you have good suggestions, I would love to hear them.

If you've got more security questions feel free to send them to me directly -- I don't read this forum every day -- or even better, get yourself a copy of my book.

Eric Lippert
Tuesday, November 26, 2002

"unsafe code" has to do with type safety and managed memory rather than code access security policies.

Pointers give you direct access to memory and the Garbage Collector is not happy with that. Using pointers is "Unsafe" as in "there could be memory leaks" or "you could be accessing a type in a not type-safely way"...

In C# you can explicitly mark a code fragment as unsafe.

Friday, November 29, 2002

*  Recent Topics

*  Fog Creek Home