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.'"
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
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.
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
> 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...
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.
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.
"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.
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.
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.