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

So what?

[mosch]

Since when does the ability to use pointers mean that something is wrong? C allows a lot of 'unsafe' code to be written, yet we're all using operating systems writting in C, with very little trouble caused by the OS itself.

Sure, it'd be great (for Sun) for everybody to rewrite the world in Java, but in reality nobody can justify requiring 50% higher CPU usage in exchange for the ability to let programmers be careless.

I'm not saying Java is a bad thing at all, merely that C# isn't any worse than C, C++, perl or python. It's a shame when a press release manages to get linked from slashdot's main page, but that's all this is. Sorry Joy, but I'm not buying it.

Re:So what?

[Hiro Antagonist]

There is a gross difference between Javascript and Java; Javascript is an in-brower scripting language with a rather vague specification. Java is a different beast entirely.

Java applets are actually different from Java applications; they don't have the ability to interact directly with the contents of the hard drive, in addition to all of the other limitations running in the JVM. The most malicious things that a Java applet can do are make lots of windows (not a problem on a Unix box), or present false information to the user -- essentially, Java applets are no more harmful than HTML.

I direct you to a pertinent section of the CERT/CC Malicious Web Scripts FAQ:

Should I disable Java applets?

The risk associated with Java applets is significantly different
from some of the other technologies. Java has a robust security
mechanism designed to deal with situations like these that prevents
sensitive information from being disclosed or client information from
being damaged.

However, Java applets written by an attacker can still be loaded
while your are viewing a legitimate web page. The problems that can
arise are similar to those involving the and other HTML
tags. For example, an attacker could develop a "Trojan Horse" program
that presented misleading information and prompted you for a password.
If you failed to recognize the malicious applet for what it was, you
could accidentally disclose sensitive information.

You must make your own determination about disabling Java applets,
based on your tolerance for these risks. If you choose to disable
Java, please see the detailed instructions below.

Re:So what?

[km790816]

Keep in mind that it is remarkably easy for an administrator, either for the local machine or the whole network, to specify .NET security policies that cannot be overriden. This includes never allowing unsafe code that has not been previously authorized by an admin. It's simple, it's powerful, it allows great inter-op with Win32 and COM.

.NET Framework Enterprise Security Policy Administration and Deployment

Re:So what?

[mcc]

And lots of administrators won't bother. The network of NT machines at the high school i went to, just for an example, had a random administrator who was given the job just becuase he'd been a teacher who knew some stuff about computers, and he knew how to set up racks of ethernet switches, and he read some books. This person didn't really have much concept of security; he just disabled anything at all anyone might possibly have wanted to have done, making the computers somewhat irritating to use. And then he went to the people who'd hired him and said, look, on the NT machines you can only run netscape and wordperfect and notepad! It is secure! You will not have to worry about the students abusing the computers! And they were content.

Despite this, there really was no security to speak of. All he'd done was limit the programs that could be executed to a small list of "approved" software. But he did it by name-- which meant that if you dropped winamp on a machine and renamed it to "notepad.exe", you could run it. The machines all had borland 5 on them, and you could execute programs you had the source to by running them in borland. And those programs could exec() others. And the write permissions were set such that one user could install Snood!, and every other user who used that particular machine forevermore would have Gator Download Assistant or whatever the hell it's called popping up every time they used netscape.

The point of my story is this: Admining is not all that simple, and many people don't try that hard at it. Windows administration gives you *lots* of options. Lots and lots of options. There's always going to be a couple configuration options that every administrator misses, somewhere, even if they're trying really hard. And lots of the administrators out there are just doing the bare minimum they have to to get their paycheck.

So, basically, even if it *is* really easy for an organisation to set up a windows xp machine to be really secure and locked down and 'safe', and even if the vast majority of deployers do go in and work out the settings just the way they're meant to,

If .NET blows up into something really, really big, then the networks of that minority of sysadmins who *don't* know what they're doing, like the one at my high school, are *all* that the next great internet worm needs to wreak quite a lot of havoc.

Just a thought.

Trustworthy Code

[SteveX]

You can use C# to write "Unsafe" code, but it's the runtime that ultimately decides whether or not to let it run. For example, if the VM that the browser creates tries to launch a C# app downloaded from the Internet, and it's "Unsafe", the CLR will refuse to run it.

Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.

I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.

- Steve

C# FUD?

[glh]

This sounds like FUD. He didn't really post any examples about what kind of problems C# has for security, that would have been helpful.

I think a lot of people are upset because MS has actually come out with something that can compare with Java finally.. The ability to write unsafe (unmanaged is what that really means, meaning the garbage collector and built in memory management features of the CLR won't touch it) is an added bonus to Java.

I think the real question is- how secure is the .NET common language runtime?

FUD machine in overdrive

[coonsta]

To serious developers not familiar with C# and .NET, either don't read Joy, or be willing to look into the details yourself. You could be embarrassed if you repeat the gist of this article as lore. At the very least, you can easily convince yourself that this article is bogus in that it doesn't mention that C# has three kinds of pointers-- managed, unmanaged and transient.

C# does allow pointers and pointer manipulation. This is mostly for programmers seeking extra performance. Like a cast in Java, declaring code as "unsafe" is equivalent to saying to the VM, "Hey, I know what I'm doing." C# pointers are definitely not as liberal as C ones (just like casts in Java are not as liberal as casts in C).

For those sincerely seeking an intelligent discussion of pointers in the CLR, see Gough, J. "Compiling for the .NET Common Language Runtime (CLR)" Prentice Hall, NJ 2002.

Uhhh, its supposed to......

[CDWert]

Uhh, and the problem with this is ???????

All lll allow this, C3 may not be a lll but theyre trying to appeal to the uper end of that segment.

C# allows you to write managed, OR unmanaged code as well, This is an option. As well as the coders ability to write "unsafe" code. YOU MUST INTENTIONALLY flag the code to be written as UNSAFE !

If you dont know what you are doing and choose to do this so frigging what ???

C# has the fundementals of a good language, forget its from MS, if it where from GNU, you;d be eating it up saying look how much better it is. I am looking forward to working with it, the .NET Visual Studio is written in C# itself , it should be pretty thouroughly debugged before its released.

Play with it for a week , if youre a beggining C programmer youll love it, if youre experienced, youll love it for the same reasons, My bet is most of the people bitching havent read or written a single line of C#, if have and dont like it Id like to know explicity WHY ?, Ms bashing aside.......

Sun shouldn't be complacent

[astrashe]

Obviously Bill Joy knows a lot more about this stuff than I do; but I think he, and many of Microsoft's critics as well as supporters, are missing a crucial piece of the puzzle.

Many of the features that have contributed to MS's insecurity were there not because MS's engineers were too dumb to think clearly about security, but because other people decided that there was an overriding business interest that the features would serve.

Specifically, these features usually tend to be part of the MS strategy of leveraging success in one sector into another. If you use office, it makes sense to choose VB as your scripting language. If you know VB, it makes sense to run IIS. That's why there's a VB interpreter inside every office app.

I think that what we've seen from MS is an official change in policy -- they're saying that business considerations now suggest that security should be the #1 priority. They're admitting that the market will punish them for security holes, and that they can't sacrifice security to establish leverage from one sector to another.

MS has always put business concerns over technical ones. For that reason, a lot of /. posters have make comments to the effect that MS isn't capable of delivering technically. It used to be the conventional wisdom here, for example, that any MS OS was destined to crash repeatedly.

It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time. This suggest that Windows crashed not because MS *couldn't* make it reliable, but because it wasn't a *priority* for them to do so. As soon as they saw a change in the business climate on the edge of their radar screen, they changed their behavior.

Windows and its applications haven't been secure because MS hasn't felt it was worth making security a priority until now. There is no evidence that they couldn't cover a lot of ground very quickly in security if that's what they decided to do. And it seems as if they've decided to do just that.

I do agree that .NET and C# are technologies that predate this new ordering of MS's priorities, and that they probably won't be very secure. Passport, the most important .NET application yet written, coded by people who ought to know the technology best, has been hacked (and patched, it's only fair to point out). If MS's people don't write secure apps with .NET, are the low end VB coders the platform is designed for going to do a better job?

But the problem that Sun faces is that MS has proven time and time again that they're willing to spend lots of money and go through lots of iterations to take a market. They're relentless. They usually don't get it right the first time, but they usually do get it right after four attempts or so.

I'll say something else that will probably get me modded down. After the recent flirtation between AOL and RedHat, I'm not sure that the moralistic arguments against MS hold up so well. Linux has been at the center of some pretty slimey stock swindles -- our gracious hosts, here at /., work for one of those companies.

Meanwhile, the Bill and Melinda Gates foundation is giving extraordinary sums of money to real nuts and bolts making the world a better place kinds of causes. Gates could literally turn out to be the most significant philanthropist in the history of the world. They're giving so much money that you can almost see a chunk of what you spend on MS going to a good cause.

All of which suggests to me that politics and the morality play that have always clouded the linux vs. windows debate should probably be put to rest.

Windows is horribly insecure -- viruses do incredible damage in the real world, especially among the least sophisticated users. That's not political, that's a fact.

But they're saying they're trying to clean up the mess. Sure, it's a big mess, and sure it's going to be a big job to clean it up. I give them credit for admitting it, and to taking on the task.

Where do you get your facts?

[Carnage4Life]

I think the difference is that .NET and C# are designed as a network-based platform; e.g., you grab code off of the 'net as you need it, rather than storing everything locally.

Really??? What gives you this idea? Java + VM is relatively equivalent to C# + CLR (as mentioned in my article that appeared on Slashdot a while ago). Code can be downloaded from the Internet and run just like with Java applets or RMI applications but this is far from the primary design of the platform .

Of all the people in the world I'd expect to criticize a technology without adequately reading up on it first, Bill Joy would have beemn one of the last I'd expect to do such a thing.

Bill Joy (and your post) go on and on about the vulnerability of network programming then ends with the reference to unsafe code which aims at giving the impression that downloaded .NET code can be unsafe. However this is incorrect, and I quote

From a technical viewpoint, the term unsafe refers to whether the program is known to be safe. Before a program is converted from intermediate language (IL) to native code, there's a part of the runtime security system known as the verifier that looks at the IL to determine whether it's safe to execute. In this context, safe means that the verifier can prove that the IL doesn't do anything unsavory.

IL safety is important for certain Microsoft .NET scenarios--it's nice to know that the chunk of code that you downloaded from a Web site isn't going to do anything bad to your machine. The default policy for remote code (either from a Web site or from a net share) is that the code must be verified safe to execute.

In other situations, it's useful to write code that can't be verified to be safe. In C#, any use of pointers generates unsafe code, as does any use of interop, such as COM interop or platform invoke.

Since you don't want to write such code inadvertently, C# requires you to use the unsafe keyword on your class or method whenever you write code that deals with pointers. When you use the unsafe keyword, the resulting IL is marked as unsafe and can only run in a fully trusted environment (usually, security policy only trusts local assemblies). In the current version of the runtime, unsafe is defined at an assembly level, so having any unsafe code in assembly makes the entire assembly unsafe.

Re:Taint mode?

[crawling_chaos]

Two words: buffer overflow

A "taint" mode would do nothing to catch these. Perl doesn't let you manipulate pointers and storage directly, so it's no big thing there. C#'s unsafe mode code does, and that's the big problem.

Sandbox for compiled code?

[kindofblue]

On a decent Unix system, it's not possible, or at least difficult, to destroy other peoples data. (Not counting, of course, buggy system call implementations.) But implemented properly, even things like "while (1) { fork(); }" will not kill the whole machine, because the OS will limit the consumption of virtual memory or CPU time, and then kill the errant process or swap it out.

So why couldn't executable code, like ActiveX or CORBA code, be sandboxed also? This should just require that the component be put into a restricted execution context, that perhaps has lower priveleges than the user's context. The component would operate like a GUEST user, and would not have access to the invoking user's priveleges and resources, like files, etc. This guest user could have it's own scheduling priorities and quotas for a subdirectory, and so on.

All the system calls, e.g. to DLL's or DSO's would be intercepted or remapped, or something like that, so that priveleges are checked and enforced, just like java does. Since modern CPU's can trap anything from illegal memory access to code or data, to illegal port access, it should be possible to fully isolate the code. Right?

Of course, the performance would be inferior because of the context switching between different privelege levels. But in a "safe" mode, this would be a fantastic way to run plugins for PDFs, Flash, a whole game, or some downloadable application.

I'm not a kernel expert, but I thought that mainframes could do this forever. What about Linux? e.g. with Wine?

BTW, this would also make peer-to-peer style distributed computation (like the SETI project) safe and still fast.

Re:Music lesson...

[Golias]

The tempered scale was needed so you could build a keyboard instrument capable of playing in tune in more than one key. Otherwise, a keyboard tuned to one scale would sound horribly dissonent when playing chords for another scale. Every Fifth, Fourth, and Octive on a tempered keyboard is perfect (there's lots of web sites that breakdown the wavelengh patterns of the perfect fifth... feel free to check it out if you care), and the thirds and chromatic notes are fudged a little bit to make that possible for every note on the keyboard.

Re:No "unsafe" code in browser?

[GCP]

.Net uses security exceptions, too. It's finer grained than Java (or ActiveX) and is managed by a security admin system local to the client. You maintain the security rules yourself, or your office "helpdesk" guys do it for you, but it's done locally.

It would be a very common thing for code to ask the runtime for permission to save a file automatically, and if permission is denied to then drop back and ask for a "safe file save" dialog box, which lets the user decide where to put the file and what to call it. The safe file save dialog doesn't even tell the app the name or location of the file that was saved. It just gives it a certificate for it, like having a valet park your car. The app doesn't know where it went, but if it wants it back, it can request it and have the contents only (not name or location) delivered back to it.

If even this is denied, then the app can save files in a walled-off section of the hard drive managed by the .Net runtime, as something akin to a super-cookie. In this region, max file size, amount of allowed disk thrashing, etc. are all moderated by the .Net runtime.

Java has nothing like this, and Bill Joy is hardly likely to bring that to your attention.