Slashdot Mirror
Bill Joy's Takes on C#
f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"
There is no C-Flat. Occasionally it is written on a piece of music, but it refers to a B. Lowering a C half a step gives you a B-Natural. Someone suggested C-Double-Falt. That would be a B-Flat.
The reason for this is on the piano, the player needs to be able to look down and determine where their hands are based on the missing black keys between the notes B,C and F,E.
Although, calling C# "B" might be interesting. But then again, there was a language B by K&R that preceded C.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
The willingness of people to post without knowing the fundamentals of .Net astounds me.
You need a special security privilege to run unsafe code. Code downloaded from the net doesn't have this permission, so it can't run unsafe code.
Pointers are pretty ubiquitous in C, and a large percentage of existing code is in C, but not 99%. Now, you can write good pointer code and bad pointer code just like anything else. To declare all code that uses pointers to be unsafe is bizarre. The danger with pointers is that you can get them pointing at weird places and get weird results. :)
Java (unless things have changed recently) does not use pointers. That, IMHO, is one of it's benefits, not because pointers make things unsafe, but because the code is easier to follow and understand.
Ben
The problem is that even "safe" Java has had security problems. Not relating to the language itself necessarily, but relating to browser/platform implementations.
See the Risks Digest:
17.39
17.83
18.18
and there are many more listed in the archives.
So until the languge/CLR mature enough, then there will be more problems with an insecure language.
Also, note that most early Java security problems were found because sun encouraged people to find them, and then Sun would fix the problems. Microsoft doesn't want people to find and disclose bugs in it's software, so it may take longer to mature security wise.
--xPhase
P.S. pardon any spelling errors, i'm tired.
The following sentence is TRUE. The previous sentence is FALSE.
Since he's the only one who got the point, despite being an AC.
;)
:)
The whole point of a safe language is to prevent a program from accessing memory it shouldn't. This means not only buffer overruns, but the ability to fabricate a pointer itself. Which means that trusted code won't compromise security with a buffer overrun, and untrusted code can't get a pointer to anything it might want (like, say, a capability descriptor it doesn't own).
And the dynamic aspect is critical. Static guarantees are useless, because in the untrusted code case you weren't there to see it compile. But if you can run code from someone else, and be assured that the VM is going to prevent the program from doing anything it shouldn't, then running untrusted code becomes feasible.
Assuming you believe the VM itself can be trusted.
This is all from memory of a lecture I had in Adv. Op Sys almost 2 years ago, so take that as you will.
The enemies of Democracy are
Bill makes a lot of sniping little attacks on C# that really amount to very little. So what if C# looks a lot like Java? That's what all the C++ people said about Java back in the day.
.Net uses for code access security, but he plays it off with the FUD statement that the security was tacked on to the framework after the C# language was built. That statement utterly fragments once you have taken a close look at the security infrastructure in the .Net framework. It isn't perfect, but from what I've seen, the tools are there to allow the clueful to secure the box with a fine degree of granularity.
Then, he confuses the C language and it's inherent propensity for buffer overruns and various other pointer-math related problems with the C syntax - which is about all C# really inherits from C.
C# executes in a runtime context, just like Java does. You have several means for controlling things like "do I let downloaded code execute file I/O?" or "do I allow unverified code to execute?"
The crucial point here is the term unverified. The C# compiler can, and by default does, generate verifiably type-safe code. It has a compiler switch (oddly enough, "/unsafe") that enables unsafe code generation that includes unverifiable code. You have to use this switch when you use a unsafe directive in your code, and you have to use that directive to employ the pointer methods that Joy references. You might even take this a step further and think that, in an config file somewhere, there is a setting to disallow unsafe code that originated from the internet.
Bill even hints at this, and I hate to think that he is disingenuous to the point that he's failed to actually follow up and look at the mechanisms
meh.
COBOL for .NET has already been done by Fujitsu.
First off, I'm primarily a hardware engineer, who writes small programs in C or assembly that deal directly with hardware. So I use pointers and other "unsafe" code a lot; they are both extremely useful and extremely frustrating when it comes to debug time.
.exe or dozens of script-containing formats, it would let it run. Surely virus writers wouldn't be _dishonest_ and change the HTML tag so their .exe's would slip through...
Pointers let you use just about any arbitrary number as an address and poke data in there. The virtual memory system might block this on the grounds that you don't have a page at that address -- but not all computers have the hardware to do that, you can still do horrible things by writing to the wrong place in the pages you do own, and if the protection does block the misplaced write, the resulting invalid page error is not pretty from the user's point of view.
Pointers can be used safely -- if you program very well, like checking every address before you use it (which takes a hell of a lot of extra code), or checking the data going into the pointer calculations to ensure that no way could a wrong value come out (which assumes you didn't make any programming mistakes). And if it is a case of running downloaded code where there is a finite chance that the programmer is _maliciously_ misusing pointers, there is no way for the computer to analyze the code and detect this before you run it. Hence Microsoft's attempt to make internet and e-mail user friendly by automatically running any included executables spawned a plague of viruses, worms, and trojans...
C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it. I don't do Java, but I am under the impression that it uses references only. That isn't enough in itself to prevent writing Java viruses, but it gives the OS a fighting chance of confining them to the sandbox...
OTOH, no computer is going to run entirely on "safe" code. At some level, the code has to read and write hardware registers. To do that, you take the numeric address of the register, and use that as a pointer. True, a good, secure OS would confine all such activities to drivers, which can only be installed by the administrator, who ought to know the difference between a driver and a trojan. But Microsoft doesn't write OS's like that -- NT/2000/XP is rather improved on DOS where direct writes to the video card were almost mandatory, but the security is still swiss cheese.
Incidentally, the original reason for C allowing all sorts of unsafe activities (pointers everywhere, strcpy with no length check, etc.) was performance. Checking the length of a string every time it was used took CPU cycles and RAM to hold the extra machine code. So the creators of C left it up to the programmer to shove in an if statement to check the length when the string was input, and to do the math and pop in another if statement anywhere it was possible for the string to grow too long. This was efficient, but puts quite a load on the programmer. About that time, I was running an 8 bit computer with 16K of RAM, clock speed under 1M, and all the accounting, class schedules, grade reports, etc. for a small college went through it. Efficiency was important! Now, who's going to notice whether the program runs in 1 millisecond or 2? It's better to be reliable. And it's necessary to get the program up and running pretty fast -- that's a lot easier if you don't have to worry about pointers going wild except when you do go to the hardware.
In C# apparently the programmer has the choice of using references and avoiding all "unsafe" code, or of declaring a module "unsafe" and programming any way that gets the job done. By making "unsafe" a PITA, they've encouraged programmers to avoid it except when absolutely necessary. I have a suspicion that once the coders get used to it, that will increase their productivity overall. In addition, it gives any tool that may run code from outside a quick way of determining whether the code was written to be safe or not. In theory...
I have serious doubts about whether that (being able to run "safe" C-sharp programs) will actually work. First off, won't a virus-writer be able to hack the tags that say "unsafe"? Second, ways to do unsafe things in "safe" code will be discovered. Third, if your OS has security like swiss cheese, no program is going to really be safe. Do e-mail viruses actually have to do anything that isn't allowed?
From what I've heard, Microsoft's idea of securing Outlook was to have it look at the HTML tag, and if it said executable pop up a warning which is incomprehensible to the people who are actually ignorant enough to get e-mail viruses. ('Yeah, it's from a trusted source. See the "From" line...') But if the HTML said "text", then it passed the attachment on to the Windows "open" command, which determines the type of the attachment by looking at the attachment, and if it was
Until that sort of thinking changes, giving people a way of tagging the programs "safe" or "unsafe" is just asking for trouble.
An Overview of Security in the .NET Framework
meh.
Actually, Fujitsu COBOL is part of the
I'm a 2000 man.
The problem with Java is that it is a closed, proprietary language whose primary design criteria has become 'get Microsoft'. In the process Java has been deliberately made less useful to windows programmers, which means the vast majority.
Care to explain just how Sun is doing this? Every Java tool I've seen has either been totally platform-neutral (which I suppose can be interpreted as 'get Microsoft') or heavily biased towards Windows users. The 1.4 JVM adds a whole load of useful new stuff - again in a platform-independant way. How is this evidence of a "get Microsoft" mentality? Or making it any less useful to Windows programmer?
And network code and runtime code safety aren't two seperate issues. They're the same issue. Making sure code that's been fetched and run from a remote source, perhaps as a small part of a larger program, doesn't go on a wild romp through the system sounds pretty damn similar to a "runtime code safety" issue to me.
Finally, what exactly do you mean by "prevent firewalls from blocking Java"? Do you mean "blocking Java applets"? "blocking Javascript"? (Which is NOT Sun, BTW)