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

Comments

Re:So what?

[BlackSol]

Uhmmm How many buffer overflow exploits & crashes have there been of the years?

But I do love C though...

Re:So what?

[good-n-nappy]

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?

Re:So what?

[Hiro Antagonist]

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.

I will admit that I'm not fantastically well-versed in .NET (who is?), but I do understand the fundamentals.

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?

Re:So what?

[GSloop]

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!

Re:FUD machine in overdrive

[roca]

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

Re:So what?

[Lazarus Short]

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.

Re:So what?

[Anonymous Brave Guy]

Uhmmm How many buffer overflow exploits & crashes have there been of the years?

Many. Then again, how many OSes written in Java have their been over the years?

Re:Sandbox for compiled code?

[josepha48]

On Linux while(1) fork() may take down the whole system. Also while (1) malloc(1024) may start to cause problems as well. Other UNIXes can be attacked by runaway proceses as well. Windows and UNIX have that problem. One process that goes awire can take down just about any system if it has the provelidges. Especially if it is run suid or as root.

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.

Re:So what?

[km790816]

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.

Sun's FUD

[markj02]

The use of "unsafe" in C# is roughly analogous to the use of JNI in Java: modules using unsafe features (or native code) are identifiable as such by the runtime, and applications with security needs can exclude them. As such, C# isn't any less safe than Java. In practice, the C# approach is likely to be safer and more secure than the Java approach, since using "unsafe" inside a C# program is much more localized and much easier to get right than writing a JNI module.

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.