I think another way of putting Joroen's question would be this: What can you do with unverified code that you couldn't also do with unmanaged code?
Both give you exactly the same amount of power. You haven't answered this question, and without an answer to this question, I don't think you've really answered the question at all. You explained what the difference between the two permissions is, and you've illustrated why both are dangerous, but I don't believe you've given us any reason to suppose that one is more dangerous than the other. If you can come up with a specific example of something that unverifiable code can do, which you couldn't also do in unmanaged code then that would be a reason. But since executable Intel binary is obviously *at least* as expressive as IL, then anything written in IL (unverifiable or not) can't possibly do anything you couldn't also do with raw executable binary. So I don't think you can. In fact I think I can prove Joroen's statement: The fact that IL gets compiled into executable binary before being executed is proof that IL can't do anything that you can't also do in unmanaged code - unmanaged code can contain arbitrary executable binary. Got some IL? Run it through the JIT compiler, copy the results into an unmanaged component, and away you go. So Danger(Unmanaged Code) >= Danger(Unverifable IL). Also, unverifiable IL is able to read and write memory in the process at will. This means there is nothing stopping it from writing some executable binary into memory and running it. This means that there is nothing stopping a piece of unverifiable IL from generating arbitrary instruction sequences and running them. So unverifiable IL can do anything that unmanaged code can. This means that Danger(Unverifiable IL) >= Danger(Unmanaged Code) So we have both: Danger(Unmanaged Code) >= Danger(Unverifable IL) and Danger (Unverifiable IL) >= Danger (Unmanaged Code) from which we must conclude: Danger(Unverifiable IL) == Danger(Unmanaged Code) So as Jeroen said, they are both exactly as dangerous as each other. The only thing I can think of that might possibly qualify Unmanaged Code as less dangerous is that you might not actually get to choose what Unmanaged Code you run. If you are limited to only being able to run whatever unmanaged components are already installed, then arguably Unmanaged Code is less powerful. However, I think given access to all system DLLs, an enterprising hacker could work out a way of owning the process and executing arbitrary code without too much effort, so it's a bit of an arbitrary distinction. Also, can you run native code embedded in a .NET component with just the Unmanaged Code permission? If so, then you can choose your own code. (Of course the only compiler that makes it straightforward to add native code is the C++ compiler, which generates...unverifiable code! So you'd need both permissions in any case. However, if you're prepared to forego such luxuries as linking and assembly, you can use ILASM and enter your native code in hex!) So at best it's an academic distinction, and if the Unmanaged Code privilege lets you run unmanaged code that you bring along yourself, it's not even that. -- Ian Griffiths DevelopMentor ----- Original Message ----- From: "Stoyan Damov" <[EMAIL PROTECTED]> Hi Jeroen, OK, it seems I've missed something, but I just tried to answer the question "why SkipVerification is considered more dangerous than UnmanagedCode?" and I'll add just one thing to my previous reply: Microsoft test if their compilers (C# and VB.NET, I know they don't do such tests on MC++) produce verifiable code. What is verifiable I don't know. I just know, that if either compiler fail to produce such code, MS take that as a severe bug and fix the compiler. So it is obvious that unverifiable code (similar to unverified code) can do something very dangerous, whatever it may be. I'm not familiar with Rotor as much as I wish, so I can't say anything more. And "why SkipVerification is not included in Everything" is a question which could be answered by some Microsoft guy, paying attention to this list. -----Original Message----- From: Jeroen Frijters [mailto:[EMAIL PROTECTED]] I have said this before, but I will say it again. From a security standpoint there is *no* difference between allowing code to skip verification or to call unmanaged code. If code has either of these two permissions, it can do whatever it wants on your system (limited, of course, by the rights of the user that runs the process). I don't think there is any good reason why SkipVerification is not included in Everything. BTW, there are more permissions that effectively give you full control over the system. Regards, Jeroen > -----Original Message----- > From: Stoyan Damov > > If you use unmanaged code, you're in control -- you can do whatever > you wish. You can or cannot do harm, it's your call. > Skipping verification means that the JITCompiler function in > MSCorEE.dll > (Microsoft Component Object Runtime Execution Engine) will not verify > the IL code before it translates it into the target CPU architecture's > assembly instructions and execute it. This will eventually > skip to check > the security permissions of the code, so it is the machine's > administrator responsibility to uncheck this option in the .NET > framework configuration MMC console. > > Does this help? > > -----Original Message----- > From: Shawn A. Van Ness [mailto:[EMAIL PROTECTED]] > > > Umm... yes, Valery -- that was part of my original question > (still unanswered). Does anyone know why SkipVerification > is considered more dangerous than UnmanagedCode? > > > 2) Why doesn't the Everything permset include the SkipVerification > > permission? Isn't UnmanagedCode more dangerous than > SkipVerification? > > -S > > > On Wed, 4 Sep 2002 10:19:59 +0200, Valery Pryamikov > <[EMAIL PROTECTED]> wrote: > > >Just in addition to previous posts to this thread: > > > >Everything PS is a set of standard permissions without skip > >verification (which is not allowed by default Everything PS). You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
