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.'"
It is possible to write unsafe code in any language that gives you access to the OS. This is called "power" as in "C is a very powerful language".
The alternative is "safe" code as in "Java is a very safe language because you can't step outside its sandbox".
C# is what happens when Java developers grow beyond the sandbox.
Uhmmm How many buffer overflow exploits & crashes have there been of the years?
But I do love C though...
$sig=$1 if($brain =~
A language can be both 'safe' and 'unsafe'. Take a look at Perl. You can do a lot of insecure things with it. But as soon as you launch with the -T switch, your script will run in a special mode. Values coming from an insecure source will be refused by potentially dangerous functions, unless you explicitely mangle them before the call. This is extremely powerful and prevents a lot of classical security flaws.
I don't know much about C#. But a taint mode for it would make the language pretty safe, despite the presence of pointers.
{{.sig}}
Yep, I think the guy's getting quite jealous of MS. Love or hate these people, the .net programming specification look very powerful, and coupled with the hard-as-nails win2k/xp combination, they will be quite hard to compete against.
.net services are basically going to be the same as before - just with a .net after them, and maybe re-written in C# now.
What Sun should really do is get off there behinds and match C# for features. From what I understand (not much admittedly), the Java VM just has to be extended to give it the breadth of additional languages that the CLI has (in terms of being able to use unsafe methods if the programmer wishes, so allowing C to work through it). The problem with Java has MS has the dominant desktop (and a good one it is now - really this is fact if you have to use them all day long), and they have the "standard" tools for programming. This will generate massive mindshare, and might get everyone from VB to C# (at least being "safe" might be good for programs knocked up at home).
On an unrelated topic, I think cloning the fundamentals of C# to a open-source basis is a very good idea. I might not agree how ximian are going about it, but at least the FSF has a parallel project that can bring the new language to the world - it could persuade casual safe programming, while allowing the breadth of accessing the OS directly.
When it comes to web services, I honestly can't see the difference between Java and C# (apart from the fact everyone will use C# as the MS-sponsored dominant language). It's all down to FUD: the
Java is great, but Bill Joy think he should go get it optimised - working faster, able to compete effectively with C#.
I stopped reading after this line:
-
"So Microsoft built ActiveX, a technique within Windows for automatically downloading and executing arbitrary programs"
Maybe Mr. Joy should read up some more:Anonymous posts are filtered.
Or wait until Microsoft adds a dialog box that says "Allow unsafe code from Microsft? 'OK' 'CANCEL' 'ALWAYS TRUST MICROSOFT'"
Then the problem is transferred to the weakest link - the user. Just like a Word file that asks if you want to run macros. How many users always know when they should say yes?
Never underestimate the power of fiber.
There's also (in theory) a special security privilege to run "potentially harmful" ActiveX scripts or Outlook macros; yet they seem to slip through on a regular basis. I have little faith in Microsoft's ability to successfully implement a decent security model, based on their track history alone. The JVM doesn't provide any memory manipulation capabilities whatsoever, so even massive bugs in the JVM don't necessarily open up your entire system. I'd place a bet that there are ways around C# security.
.NET (who is?), but I do understand the fundamentals.
I will admit that I'm not fantastically well-versed in
Furthermore, using code that handles memory directly is a lousy way to implement platform independent software; why do you think there are so many little-to-big-to-little endian conversion functions in C?
--
I Hit the Karma Cap, and All I Got Was This Lousy
Security in .NET has been built into the foundations of the CLR, not added as an afterthought as Bill Joy implies. Read more about it at the .NET Framework Security Overview. The reason Microsoft seems so cocky about their new "trustworthy computing" crusade is because they know their new framework makes it a lot easier to follow through on their promises. Although there is still room for programmer error, that room is now the size of a broom closet, not a stadium.
Oh right, that would be as opposed to those 100% safe java scripts.
There's no such thing as a "Java script". Java is not a scripting language. If you're referring to JavaScript, that has nothing to do with Java except the name.
The key point here is memory safety, which C (and C#'s with the unsafe keyword) lack. In a language with memory safety, buffer overrun vulnerabilities and the like can't happen.
Typically, memory safety is tied to type safety. (But, memory safety really has nothing to do with pointers. For instance, SML/NJ allows pointers, but is memory safe, since the type system won't let you treat an integer as a pointer. In SML/NJ, the type system essentially provides you with a proof that your code is memory safe). So, if your code type checks, it *is* memory safe.
The two concepts are distinct, though. Java is memory safe, but you can break the type system with casting. So their is no *static* guarantee that your code is memory safe, but the VM includes runtime checks to make this a dynamic guarantee.
So, it would be perfectly OK for GM to put a "change oil" button on the dashboard of all cars. When you push the button, all the oil is dumped out of the engine.
Every year around 250,000 people destroy their cars from this button.
Who's problem is it? The user - probably. But it's GM's problem too. Any problem that occurs in significant numbers is a DESIGN problem. Sure, the user shouldn't, but good design will make it more difficult for a user to screw themselves. It will ALWAYS still be possible - the goal is to make it less likely that the user will do so unwittingly.
Thus, MS's bugs are mostly MS's fault. They don't care about decent design. To blame the user is a cop-out.
Cheers!
> Like a cast in Java, declaring code as "unsafe" is
> equivalent to saying to the VM, "Hey, I know what
> I'm doing."
This is wrong. A Java downcast is dynamically checked and cannot compromise the integrity of the virtual machine. It is not "unsafe" in any meaningful sense of the word.
...even English. To try it, go into a biker bar and tell the toughest looking guy you liked his mother. If that doesn't do it, ask him if he has a sister. Make sure to call 911 before you do ;-)
:-)
Yes, C# has an unsafe mode. So does Perl, Python, Java Script, and guess what--Java.
The only difference is that C# lets you write unsafe code in C#. In Perl, Python, etc.. you would write a shared library (or link extensions into the language executable). And then of course you have to trust that the shared library is "safe."
Yes, there are going to be security holes in programs written in C#. Only careful programming, and as much peer review as possible can reduce those mistakes. In the end, only time will tell if an application has holes.
Long live the Department of FUD! Let's go scare some suits
--AM
I'm not a computer scientist, just a unix admin. My question is: Since when has operating on pointers been considered unsafe?
That statement is a dangerous one for you reputation as a good admin. Almost every bug or security hole is related to bad pointer handling. Pointers are a very powerful tool, but as such, they are extremely dangerous, specially when used in a not type-safe environment.
As for your claim of 99.9% of the code to be considered as unsafe, i dont think the percentage is so big, but it comes quite near. How do you think the patchers and support staff live from?. It's an inevitable part of software.
Just for the record, JAVA does NOT have pointers.
Languages that use direct memory manipulation do have drawbacks in the safe/secure area.
I don't care how good a C/C++ programmer you are, you WILL create buffer overrun situations in your code. Period. End of story.
All it takes is one program running as a priveleged user to have a buffer overrun and bam, compromised system.
Thats not to say Java doesn't have the same problem. All it takes is one buffer overrun situation in the VM and boom, compromised system. It is probably safer though, you only have one large c/c++ program that many folks are looking at.
Anyhow, my opinion.
Barjam
ROFL
My point is, that when your first priority is to protect stupid people from doing stupid things, you often also protect smart people from doing smart things.
Maybe I'm just old-fashioned, but I like to understand decisions which I make.
But I don't know if you understood me, I was commenting:
and I said, that: Do you really disagree with that?~shiny
WILL HACK FOR $$$
I'm not too well-versed on .NET (or compiler/interpreter issues in general), so maybe this is a stupid question, but just because C# has features to manipulate "pointers" doesn't necessarily mean that you're really playing with actual memory addresses, does it? It could just be an (internally bounds-checked) index into a big ol' byte array or something, right?
e.g.
print(foo);
// interpreter looks up "foo" in the symbol
// table, gets (e.g.) 23, and outputs memory[23]
fooaddr = address_of(foo);
// interpreter looks up "foo" in the symbol
// table, again gets 23; looks up "fooaddr",
// gets 24, and does memory[24] = 23
fooaddr = fooaddr + 10;
print value_at(fooadr);
// interpreter compares fooaddr (which is 33) to
// mem_size (which is 30), and dies (or whatever)
As long as you test in your "value_at" function, you should be clear (from this particular problem, at least)
Oh, and nice nick, BTW.
The most valuable commodity I know of is information. - Michael Douglas as Gordon Gekko, Wall Street
As others have said time and time again, it's about the developer who is writing the code. Sure it's FUD, but everyone is throwing it in every direction. The only thing half way useful from the article is about each company's approach to development, which doesn't necessarily validate their products. It's good people are thinking critically about the article and poking holes in Bill Joy's article. The only problem with providing the power and benefit of unsafe code is, when some uses it inappropriately or incorrectly, it creates headaches for everyone in the project. No news there. Good developers will spend appropriate time to learn the tool and use it "correctly." Here's to the hope C# will not only be developer candy, but that it will promote good coding practices.
> When you use the unsafe keyword, the resulting IL is marked as unsafe and can only run in a fully trusted environment
This bit still scares me. Does this mean that the C# compiler marks the IL as unsafe, and that the CLR trusts this marking? If that's the case, what is there to stop someone from bypassing the compiler, and editing the IL directly? (And please don't tell me it has anything to do with signed, trusted code :)
At least the Java model is based on fairly solid theory. The environment has a lot of nice properties which make it easy for the JVM to ensure that all code executed is safe. It begins with the position, "don't trust this code," and refuses to execute anything which it cannot prove to be safe. It doesn't rely on the programmer, or the compiler, to flag unsafe sections of code.
Living better through chemicals
Many. Then again, how many OSes written in Java have their been over the years?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Building a system with the sandbox design in minds is easier than taking an existing system and putting it in a sandbox. Active X is already out there. How do you handle the existing Active X and put that in a box? You'd basically have to redesign active X. Word, Excell and Access all rely heavily on VB macros. How do you put them in a sandbox? Actually that may be easier to do but it would also be limiting. In the sandbox that Javascript runs in you are not supposed to be able to access files on the users filesystem. (note not supposed to there have been errors on that though). The idea was there though.
Okay so you operate it in a GUEST account. If that guest is set up or can access files there goes security.
The reality is that 28 days is not enought time to focus on security and Microsoft does not have a good track record when it comes to security. While it may be possible to start building in security into the existing system. Security is a continuous effort that must be thought of as part of the design. When a programmer creates a new language they must start to think security right off the bat. This was done with Java, but not C#.
I say good luck Microsoft, but you have a lot of work ahead of you to prove to me that you can get security right without comprimising usability.
Only 'flamers' flame!
On a side note: Does anyone really expect Joy to say anything even remotely suportive of C#. Even if C#/.NET was the greatest thing since sliced bread, (I'm not saying it is) does anyone really expect anyone from Sun, especially one of the guys that created Java, to say anything possitive, supportive?
It's like asking BillG his opinion on Linux or LarryE his opinion on DB2.
Let's keep things in perspective, kids.
A speech...
In reality Joy wishes to convince non-technical people that Java is superior to C#, and through that, all of .NET... Sun's usefulness is shrinking with time, and they realize one of their most valuable assets in the future will be Java. They have no desire for MS to sack their Java developers, like free unices, Windows, and robust server solutions built around the x86 are sacking their server market...
By convincing employers that might not know their ass from their elbow that Java is innately superior and more secure, this will shape what sort of things people will actively use to solve problems, such as technical folk with no choice but to do what their employers ask of them...
Everyone seems to assume that most C# programs will not have unsafe constructs, making it generally practical to disallow code with unsafe constructs.
I'm willing to bet that most C# code will contain unsafe constructs. Programmers mostly come from a C background and, like all other humans, are basically lazy. Since unsafe code is both faster and easier to write, there will be tremendous impetus to write unsafe code so as "to get it done now".
With enough code that has unsafe constructs in it, system admins/users will end up allowing unsafe code to run by default.
In almost all cases, users want the maximum features and least security possible. Java's "least secure" mode is a lot better than "C#"s. Therefore Java is likely to be a lot more secure than C#. Blame the users? Sure. But it's the security that is actually used that counts, not what's available.
Naturally, you should make it possible for lumberjacks to use chainsaws. It is also "common sense" that you don't give a chainsaw to your 5 year old to play with.
Choice is very good, but too much choice is generally bad. Particularly when you give the options to people which clearly shouldn't have them.
This is why it's not a good idea to let unsafe code be executed on a machine. Even if the user presses "OK" and thus at least the programmer or Microsoft can't be blamed. After all, if the user had any common sense he would know that it is bad to run untrusted code.
Unfortunately common sense isn't.
And if people didn't agree to things they didn't understand a lot of people would never get past the first install prompt they faced. As said, if you make user friendly programs and OS's, then you should expect that you will have a lot of computer novices behind the wheels.
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.
Java is safe because it is interpreted. Sure, it is compiled, but the compiled code doesn't run on hardware.
.NET code is interpreted, then they can make it safe. If they have a silly marker saying "This code is safe because it doesn't operate on memory directly", then that is just silly because some hacker can easily remove this marker.
If
Running code downloaded from the network, directly on your hardware, will always be somewhat dangerous. Of course that is what operating systems are for. However, there is always some way to figure out how to run malicious code in a privileged fashion.
Linux = UNIX
Gnome = MacOS/Windows GUI (without the consistency.)
Gimp = Photoshop (without the cluefulness.)
Your point is? There are certainly grounds to criticize Microsoft, but sticking to legitimate complaints rather than knee-jerk name calling does a lot of good.
I'm an old MacOS user, and I lost count of how many technologies cut their teeth as features in the MacOS, then became successful as MS refined them and implemented them in Windows.
It's not as if that's a *bad* thing.
--the verb
There seems to be a load of discussion on the actual functionalities and implementations of C#/.NET so far. But I think we should all take a step back and look at how MS approached the whole process of designing a supposedly platform-independent, net-oriented runtime system + language.
I think we all agree that being the language of the NET, security is of priority #1, way ahead of functionality and flexibility. However, to design any kind of secure system, it is essential that you make the strictest system, and only then relax the security restrictions to allow more functionality. But it looks like MS wanted C# to do everything, and then add security as an afterthought. It is dangerous to achieve security by incrementally restricting the system.
"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."
This is not true. C++ references are exactly like pointers, except that you cannot rebind them. With a pointer you can point it one place, then point it another. With a reference you have to define the place it points when you create it and you cannot move it later. So:
Foo& f = *(Foo*)0;
cout << f.someValue;
will still shoot you in the foot just as effectively as:
Foo* f = 0;
printf("%d", f.someValue);
OTOH, in Java, they call everything a reference, but it's really more like a C pointer except that there is no pointer arithmetic. Oh, and it *is* always checked. Try to use a null reference? Exception. Try to typecast a reference in an invalid way? Exception.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
You make a good point, bringing up the JNI. I would like to continue this by criticisizing language designers who like to claim that their language doesn't let you do anything dangerous, but then provide a native interface so that when you need to do something you can't do in their language you can link to the routine written in C or whatever. They can then bounce around when programs have security flaws, saying that "Java is secure" and "Well the hole was in the C part" etc.
Especially when the extra functionality you need is written for this application and is not just a link to a previously-written module it is damn handy being able to write it in the same language. In my view it is very cool of MS to allow you to use c# for everything.
graspee
On a side note: Does anyone really expect Joy to say anything even remotely suportive of C#. Even if C#/.NET was the greatest thing since sliced bread, (I'm not saying it is) does anyone really expect anyone from Sun, especially one of the guys that created Java, to say anything possitive, supportive?
:D
:D
So you mean no Java developers can critize C#, especially those who work in SUN, even when the opinions might be reasonable and valid?
Tell Microsoft stop calling GPL virus!
Let's keep things in perspective, kids.
I know you are not calling me kids, but I found this statement funny when you said it.
He should have checked out the MSDN docs. He should also have read some security studies or even done his own. Perhaps then he would have realized that the security of the CLR has nothing to do with an arbitrary bit set to mark a block of code as "safe", but rather to do with a type-safety verifier that is completely independent of the compiler and language used to generate the code in question.
C# is not tied to the CLR like Java is tied to the JVM. The CLR (Common Language Runtime) is designed to run IL code, and there are compilers for many different languages besides just C# that can generate IL. That said, it should be clear that the security of a C# program is not derived from the C# compiler. It comes from the CLR, so the security policy is enforced at the IL level, not prior to compilation. (It would be laughable if the security of the CLR was enforced only by the C# compiler rejecting "unsafe" code. I'd just write my own C# compiler that allowed it, or I'd whip out my IL assembler.)
The "unsafe" marking of code occurs only at the source code level. Whether or not code is considered type-safe by the CLR is not determined by an arbitrary flag set by the developer; it's a function of the IL code itself. It needs to be that way, otherwise programs compiled with my evil compiler for my own non-type-safe language would slip through the cracks. Note that even if my IL code is actually type-safe, if the CLR's type-safety verifier can't prove it, it won't be considered type-safe.
That being said, "unsafe" is just a compiler feature. Perhaps Bill Joy would have had nothing to say if Microsoft had decided to use a keyword other than "unsafe", like maybe "dont_generate_an_error_at_compile_time_if_the_cod e_inside_this_block_fails_the_type_safety_check_ev en_though_it_is_going_to_fail_when_the_CLR_tries_t o_run_it_in_a_context_that_requires_type_safety". (Actually you can achieve this if you don't mind adding a #define to your C# source and then running it through a C preprocessor first.)
But why take my word for it? Check out an interesting study into C# and the CLR's security done by some students at Rice University at http://www.owlnet.rice.edu/~jsinger/comp527/propos al.html. They have a lot of detail there about tests they ran, as well as a good paper summing up their results.
D
It's funny that everyone here is saying Sun is spewing FUD and joking about Slashdot being rigidly anti-MS. As far as I can see, almost everyone here is rigidly pro-Microsoft and eager to heap abuse on Java and praise on Brave Microsoft for making the "Genius" C# and .NET.
.NET is going to be asking your permission all the time. Let me tell you, I just spent the day with a secretary in a law office who was just wrapping her head around loading and saving documents. If her web browser asks her whether or not she "trusts" someone's code, she's going to just click a button at random no matter how many times I try to explain what to do.
.NET, without having ironclad and unequivocal guarantees - as Java can give you - you're setting yourself up to have another MS security disaster.
There's a tremendous amount of well-rated lies here about the article itself. It's really astounding in its volume - ranting on for pages about how Bill Joy is jealous, and C#'s pointers are totally safe, and Sun is making up lies about C#... "Insightful"! It's like some kind of geek guilt or something - we have to be hard on ourselves, and have a backlash against our backlash now?
I prefer to actually look at the objective truth on a given day. What's the article about? Joy is saying that C# doesn't force you to be safe. It lets you choose. And the problem is that if you let people choose to be unsafe, then they sometimes will be unsafe, because it's easier, or faster, or because they don't know any better.
Despite rampant misquoting here to the contrary, Joy wrote explicitly that he knows pointer-massaging code is marked "unsafe" in C#, and is recognized and treated differently by the CLR. It's right there in the article.
The point is that it just brings us back to square one security-wise - to ActiveX. Break out your digital signatures. Do you trust this code? Yes or no. If you want to run it, you better. Some of it might be "unsafe." Once you start flinging pointer arithmetic around, you can stand up and piss right over the sandbox wall.
So many choices. So much freedom.
Joy's point is that in the context of network computing, certain kinds of flexibility are dangerous and ultimately destructive.
I can just see all these rah-rah-C# people making the same kind of arguments I'm hearing about pointers for being able to do powerful word macros and having IE rendering emails. It's so powerful! "Just don't open any word documents from people you don't trust!" they say. Heh.
What we've learned is that we can't dump this security dillemma on the world under the guise of "choice." We've made that mistake (MS certainly has) over and over again, and the result is the same every time. For something like
We're on the road to Tycho.