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

Taint mode?

[chrysalis]

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.

Joy FUD Club

[Master Of Ninja]

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.

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 .net services are basically going to be the same as before - just with a .net after them, and maybe re-written in C# now.

Java is great, but Bill Joy think he should go get it optimised - working faster, able to compete effectively with C#.

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:define "unsafe" again please

[Anonymous Coward]

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.

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?

[Shiny Metal S.]

You're right. If there were no chainsaws, people wouldn't cut off their fingers with them. But that would also mean that other people won't be able to effectively do their work.

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:

Just like a Word file that asks if you want to run macros. How many users always know when they should say yes?

and I said, that:

It's a good practice to not agree for anything you don't understand... When you don't know if you should say yes - just say no.

Do you really disagree with that?

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:Where do you get your facts?

[cicadia]

First off, Joy admits that code declared as unsafe "cannot be executed in an untrusted environment," at least according to the spec. He goes on to point out that we're trusting Microsoft's implementation here, which hasn't always been the best policy, at least for security issues.

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

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.

Re:Where do you get your facts?

[west]

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.

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.