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.'"
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
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
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.
.NET common language runtime?
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
Wow, so Sun doesn't like MS technologies. What's next, Microsoft spreading FUD about Open Source?
"In unsafe code it is possible to declare and operate on pointers"
I'm not a computer scientist, just a unix admin. My question is: Since when has operating on pointers been considered unsafe? Pardon my lack of understanding, but with that definition, wouldn't 99.9% of all code then be considered unsafe? And does't JAAVA use pointers too? Honestly I duno..
It isn't a lie if you belive it.
I still don't understand what's so evil about C#. If you don't want to use it, you don't have to. But personally, I find that not using C# leaves a sizable gap in several different keys, meaning a lot of stuff comes out just sounding wrong.
"What's so random about flipping a coin? Ever heard of the I Ching?"
There is no C-Flat. Occasionally it is written on a piece of music, but it refers to a B. Lowering a C half a step gives you a B-Natural. Someone suggested C-Double-Falt. That would be a B-Flat.
The reason for this is on the piano, the player needs to be able to look down and determine where their hands are based on the missing black keys between the notes B,C and F,E.
Although, calling C# "B" might be interesting. But then again, there was a language B by K&R that preceded C.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
I think someone should throw the gauntlet down: let's see Bill Joy come up with a truly secure code for Java. And I mean some that meets the C2 standards for security, too.
What is known is that you can write some pretty destructive programs in Java, too. Why do you think Network Associates and Symantec have spent a lot of time with their antivirus programs to protect against unsafe Java programs?
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.
Would know that right after he quoted from C# specification about unsafe code, he quoted again
""Unsafe code is in fact a 'safe' feature," the C# specification continues, "from the perspective of both developers and users. Unsafe code must be clearly marked with the modifier 'unsafe,' so developers can't possibly use unsafe features accidentally, and the execution engine works to ensure that unsafe code cannot be executed in an untrusted environment.""
Seems like a good idea to me, whats wrong with that?
Uhh, and the problem with this is ???????
.NET Visual Studio is written in C# itself , it should be pretty thouroughly debugged before its released.
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
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.......
Sig went tro...aahemmm.....fishing........
Just because the language supports *clearly marked* "unsafe" (as in, the programmer is able to shoot-himself-in-foot) coding practices, does not mean that IE will allow controls that require that feature to run.
what will make this unsafe feature any different thatn any other unsafe feature that IE runs?
Thanks to file sharing, I purchase more CDs
Thanks to the RIAA, I buy them used...
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}}
There's been alot of controversy lately over security holes in programming languages. There is one language that has stood the test of time and proven to be the most secure language of all, with a record zero (0) reported security holes.
Here is the link if you want to learn more.
I Heart Sorting Networks
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.
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.
Java was a step in the right direction. C# may be promoted by Microsoft heavily, but the prospect of "unsafe" code is only going to send up red flags with the average users. The average desktop user doesn't want to have to worry about safe/unsafe code - they just want to be able to browse the web safely - which is what Java already provides. Sorry, Microsoft, but Java already does better what C# was intended to do.
The society for a thought-free internet welcomes you.
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.
/. 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.
.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?
/., work for one of those companies.
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
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
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
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.
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
I mean this guy is the chief scientist of Sun Microsystems and the co-author of "The Java language specification", what exactly do you expect him to say about C# ?
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.'
First of all (go ahead and call me a troll, like I give a fuck): it's not nice to call someone BJ, even if their initials are in fact B. J.
"Unsafe code" has no meaning to Microsoft. I'll put it this way, code monkeys are spewing out of Devry and ITT tech (and 4 year institutions under the mask of "computer information systems" majors) daily, with no real understanding of what makes good software development, and they want a language that will be as easy as possible and will fulfill all the buzzwords like "object oriented" and "self-specification." C# will provide this, and Microsoft will support it.
~ now you know
Since he's the only one who got the point, despite being an AC.
;)
:)
The whole point of a safe language is to prevent a program from accessing memory it shouldn't. This means not only buffer overruns, but the ability to fabricate a pointer itself. Which means that trusted code won't compromise security with a buffer overrun, and untrusted code can't get a pointer to anything it might want (like, say, a capability descriptor it doesn't own).
And the dynamic aspect is critical. Static guarantees are useless, because in the untrusted code case you weren't there to see it compile. But if you can run code from someone else, and be assured that the VM is going to prevent the program from doing anything it shouldn't, then running untrusted code becomes feasible.
Assuming you believe the VM itself can be trusted.
This is all from memory of a lecture I had in Adv. Op Sys almost 2 years ago, so take that as you will.
The enemies of Democracy are
...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
Bill makes a lot of sniping little attacks on C# that really amount to very little. So what if C# looks a lot like Java? That's what all the C++ people said about Java back in the day.
.Net uses for code access security, but he plays it off with the FUD statement that the security was tacked on to the framework after the C# language was built. That statement utterly fragments once you have taken a close look at the security infrastructure in the .Net framework. It isn't perfect, but from what I've seen, the tools are there to allow the clueful to secure the box with a fine degree of granularity.
Then, he confuses the C language and it's inherent propensity for buffer overruns and various other pointer-math related problems with the C syntax - which is about all C# really inherits from C.
C# executes in a runtime context, just like Java does. You have several means for controlling things like "do I let downloaded code execute file I/O?" or "do I allow unverified code to execute?"
The crucial point here is the term unverified. The C# compiler can, and by default does, generate verifiably type-safe code. It has a compiler switch (oddly enough, "/unsafe") that enables unsafe code generation that includes unverifiable code. You have to use this switch when you use a unsafe directive in your code, and you have to use that directive to employ the pointer methods that Joy references. You might even take this a step further and think that, in an config file somewhere, there is a setting to disallow unsafe code that originated from the internet.
Bill even hints at this, and I hate to think that he is disingenuous to the point that he's failed to actually follow up and look at the mechanisms
meh.
MS Creates a language that is similar to Java, and even though it has been left unsaid by MS, they would like to lure Java programmers away fron Sun and towards .NET.
MS Creates ads in DDJ and other tech publications with benchmarks that show C# trouncing Java J2EE.
This is almost certianly a FUD tactic in retaliation to MS trying to lure developers away from the Java platform.
The fallacy in your argument is that for every 10 developers who are working to write secure code (whether in a safe or unsafe language) there are at least 1 or 2 crackers working specifically to exploit how the code and the environment it runs in are unsafe. C# inherently makes this easier than java. Why would anyone allow .NET/C# code run on their machine is a mystery, because given Microsoft's track record, it seems that it will likely be yet another fruitful petri dish for crackers.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Do the following search and replace in this article:
s/C#/Java/
s/unsafe/native/
And it still is true. Java has it's own "native" methods, which have all the same problems that C#'s unsafe methods have. In C#'s case it's a bit easier to work with because you don't have to change languages, (Java native methods can't be written in Java).
Man, I hope someone calls Joy on his hypocracy.
sigs are a waste of space
C# is just Microsoft's imitation of Db. Once again, they take something that's been around since the equally tempered scale and claim it's an innovation.
...before unveiling its secret weapon in the language wars:
COBOL#!
Yes, with the power of COBOL# Sun will be able to monopolize the huge untapped market of legacy COBOL code that could be easily modified and brought up to cross-platform, bytecode standards.
Since there is so much more legacy COBOL code than C/C++ (75-80% of all existing code in businesses is still COBOL), Sun will one-up Microsoft, and along with Java will be able to win over developers with its advanced security features like a rigid sandbox and no direct memory manipulation.
Next up for Sun, Java++... it's rumored that Sun's pulling out all the stops with this one, and even including a full-fledged graphical developing environment with the J++DK, complete with an intelligent "Programming Assistant" that will warn you when you're writing unsafe code! Dancing Bill Joy or paper clip graphics optional.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
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
We can do this in java too- but instead of being able to write unsafe code in java we're forced to use JNI and code in C.
ROFL
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.
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.
What kind of syntatical gobbeldy-gook is this!?!
.EXE header that states "the unsafe flag was set in the code, so don't run it if you don't run "unsafe" code...
If I put the keyword UNSAFE in front of any line of code, C# generates a flag (similar to CONST in C/C++), that sends the keyword all the way down to the code emitter which sets a flag in the
There's NOTHING, NADA, ZIP in this system that makes the code in this program "safe". All you're REALLY saying is "MICROSOFT WARRANTS THAT THIS CODE HAS NO POINTERS! (TM)"
That's what Joy is saying... When Microsoft has to state in their documentation "The keyword UNSAFE, marks code that is UNSAFE to run, because the code being run would be UNSAFE when it is run. This actually makes the code SAFE." There's something VERY WRONG here...
Stop buying the Orwellian newspeak... THE EMPEROR HAS NO CLOTHES!
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.
I think we can all agree that if there was any attempt to secure IE and Outlook from threats, it was either ignored or done half-assed.
Just to be careful, I wouldn't compare a half-assed attempt at security to thier upcoming crusade (last crusade it was the Internet).
I'd place a bet that there are ways around C# security.
We'll have to wait and see. From what I understand, MS hasn't implemented a sandbox for executing applet like applications. When they do, I'm pretty sure it will be as restrictive and secure as the JVM (obviously pointer manipulation wouldn't be allowed). Why wouldn't they? It's not like they don't have experience making virtual machines.
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?
It's not for building cross-platform code. It's for developing system code when you need to write system code.
"Communism is like having one [local] phone company " - Lenny Bruce
i suggest you read the man page for strncpy(3). The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. this is a classic source of bugs in string manipulating code written in C.
whose afraid the world is going to be taken over by giant genetically engineered killer robots or something? Probably afraid the AI will be written in C#.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
An Overview of Security in the .NET Framework
meh.
Notice that Joy's article starts off sounding very technical, but never quite gets to any specific technical flaw in .Net. He just implies that it probably has a lot, without offering a single example, based on historical complaints about the company.
If you think the "untrusted code" part was a (single) example, note that he doesn't actually point out any specific flaw.
Java itself allows a program to delete user's entire hard drive, or write the binary op codes for a virus into a file and label it "readmeNOW.exe", if that user chooses to run the program as a standalone app. So Java has the concept of trusted and untrusted, too.
If Joy wants to convince a technical audience that C# is dangerously insecure, you'd think he could come up with an example.
Otherwise, it's nothing more than a fluff "I just don't like Microsoft, the company" piece.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Some tasks simply need low-level features. If you want to use a high-level language most of the time, you have got several choices: You can write the low-level parts in a different, low-level language, you can try to outgess the compiler vendor and write source code which compiles to the required machine code using a specific compiler version (in many cases, this is the C approach), or you can use a high-level language which supports low-level programming. The third choice does not have to be the worst, especially if the low-level language features are clearly separated from the high-level ones (C fails miserably in this area).
Remember that many mission-critical computer systems are implemented in Ada, which offers a wide range of very low-level features (interrupt handling, representation clauses, unchecked conversion of objects, and so on). Unlike C, there is also explicit support for machine addresses and address arithmetic.
However, you should keep in mind that only certain types of security problems can be avoided automatically by choosing an appropriate programming language. Buffer overflow and format string bugs are found in almost all C software, but they are not the only cause of problems.
You've been taken in by the anit MS FUD.
Here is the most recent definition from MSDN:
"A set of technologies that enables software
components to interact with one another in a
networked environment, regardless of the language
in which they were created. ActiveX(TM) is built on
the Component Object Model (COM). "
Quite a step from "automatically downloading and
executing arbitrary programs" don't you think?
More specifically:
"An ActiveX control is essentially a simple OLE
object that supports the IUnknown interface. It
usually supports many more interfaces in order to
offer functionality, but all additional
interfaces can be viewed as optional and, as
such, a container should not rely on any
additional interfaces being supported. "
Anonymous posts are filtered.
Alas, I doubt anyone will be reading this, but I'll say it anyway:
Java's security model always felt tacked on to me, but even still, it's pretty decent for the kinds of security issues it was meant to deal with. The problem is that Java can still be used to create viruses and other nasty problems, especially if it can sweet talk to user into giving the Java code more permissions than it would otherwise have. The same thing is true of ActiveX: all the security in the world won't protect you from a user who cranks the security in his IE down a few notches. The reason users would do this is to get access to a control or java app that can do something interesting or useful. For example, a virus scan of your harddrive.
This leads me to a basic observation: the usefulness and capabilities of a language or programming environment is directly proportional to the amount of damage it can inflict on a system. Both languages and environments have their benefits and drawbacks, but deciding based on security is pointless: security is fundamentally a user-developer level issue. No amount of language-level or environment-level features can make computing secure if the user and developer aren't willing to think securely as well. If you do add more secure language and environment security measures, then the usefuleness of your language/environment decreases (e.g., to protect your local hard-drived files from unwanted operations, you lose the ability to save/read anywhere on your harddrive from your application). You cannot have a useful programming language/environment and still make guaranteed secure programs.
C#'s unsafe section problems are not security problems, but robustness problems. The unsafe sections make it very easy to create code as crashable and bug ridden as a pure C/C++ app! Java's constraints don't make it more secure than C#, but they do make it easier to write robust code.
Even with the unsafe sections, you can still write really high quality C# code because no language/environment feature can ever replace the programmer's diligence in writing secure code. And if you want code that's less bug-ridden and more robust, avoid unsafe code sections like the plague.
My greatest qualm with C#'s unsafe section is knowing that a bunch of programmers raised on MS's crappy coding style will create components and other applications with great reams of unsafe code forcing everyone using .NET to drop their security precautions in order to get basic applications running thus creating the backdoor every script kiddie is waiting for.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Actually, Fujitsu COBOL is part of the
I'm a 2000 man.
What a wonderful combination!
-- Alastair
I suspect that Bill Joy's article is not totally objective here. I was almost expecting the word "Advertisement below" to flash above this article.
.NET and C#.
See, the problem is that MS may have the killer Java technology here on the server side, and Sun smells it. So expect to hear more from people at Sun bashing hard on
What's Bill's point anyway? Ok, he knows stuff as he wrote vi and csh both in C, so he probably got into pointer trouble while writing his code. But, I am not sure about what he claims here. Is he asking MS to add the keyword "unsafe" into the C# language and is he bitching because MS already moved to the ECMA?
At least MS had the decency to move their language to a standard body right away, instead of tip toeing for about 2 years like Sun did with Java. And Sun still controls Java BTW.
Visibly, the guy with the gray goo on top of his head is running of fuel. It shows.
PPA, the girl next door.
-- I feel better now. Thanks for asking.
I've been reading a lot of comments about the IL code having some sort of flag mechanism indicating unsafe portions.
.exe header?
My question is this: since the end-user JIT executes IL, what stops someone from editing the IL so that it becomes 'unflagged' as unsafe and tricks the end-user into thinking it is a safe portion? Are there a group of unsafe instructions? Is the IL obfuscated in some way? Or is it just as simple as an 'unsafe=1' in the
I think many of our concerns about unsafe code could be answered by knowing these details. Could someone with the technical knowledge step forward?
----- rL
Despite its flaws it is much better than anything MicroSoft has had before from a developer's viewpoint. It makes it easy to write money-making apps on the worlds large operating system.
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
Don't you get it? "...and so forth".
Forth, you know?
On second thought, if you haven't heard of
Bill Joy before...
I mean, he's Bill Joy. If he can't knock out a safety-checker for C# units in a couple of weeks, then he's not the Bill Joy we grew up with.
--Blair
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.
I like Java. I'd just like to point out that even in Java you have safe and unsafe runtime environments.
I could easily write a Java app that would write binary op codes for a virus directly into some of your favorite application executables. The sandbox runtime wouldn't execute you it, but the standalone runtime would if you told it to.
Bill Joy claims that there is a form of coding called "unsafe" in C# and expects you to draw the conclusion that C# is dangerous to use. Pretty pathetic argument for someone with his technical background.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.
No, that's not necessarily what we want, at least in the long run. It's more limiting than necessary for many purposes.
.Net has a security model that lets you configure your runtime to allow various levels of access depending on digital signature. If I'm the family computer guru, I might set up my parents' computers and my sister's computer to run -- with full access -- anything stamped with my digital signature. I would do that locally on their machines during a holiday visit.
After setting the security admin rules locally on their machines, I can thereafter deploy full-power software that I write to their (and my own!) browsers.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
It's a good question. .Net has several categories of pointer. Some are there to allow you to use efficient indirection as a programming paradigm without simultaneously exposing the underlying memory system of the machine. The two do *not* have to go together.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
That's the sound of the sarcasm plane darting swiftly over your head, safely unseen. If you look up quickly you might be able to spot the vapor trail.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Java's code does run on hardware.
The Java compiler compiles it to byte code. Then at run-time the JIT (just-in-time compiler) available on many Java platforms compiles the byte code to native code.
C# does the same thing. It compiles to a byte code called MSIL, and then at run-time it gets JITed to native code. And, just like Java, a C# app that you run from the web gets run in a sandbox to protect the user from malicious code.
Donate background CPU time to fight cancer.
Java has had for quite a while the ability to call C code, external DLL's, or whatever - JNI, the Java Native Interface. In fact it's also defined how external code (well, C and C++) can call into Java as well and launch a JVM from inside a native program. I've used it myself and it works just fine.
Apart from that, I can't really think of any features the CLR or C# language has that Java is missing. What you could possibly say is missing are tools like MS provides - though Java does have many amazing tools like TogetherJ, JBuilder, Netbeans, and others. Still if for sme reason you bought into the cross-language idea (in my mind a total farce but I can see where people would find it appealing on the surface) the JVM does support many languages but there's really no tool that brings them all together at the moment.
I agree with you on the web services aspect.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What I like a lot about about the applet model is not just that it keeps things in the sandbox, it's how fine grained your control is over what the sadbox really is.
An applet can do anything up to altering parts of your OS if you give it the scope. It can also be given just the barest permissions it needs, such as the ability to read and write to one directory on your computer and no other.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I dunno, but Royal Dutch (Shell), one of the biggest oil companies in the world, uses Win2k worldwide in their wan (more than 70.000 machines), server, desktops, you name it.
Nasdaq also uses win2k based solutions.
Anyway, my NT server has now an uptime of 127 days and counting. Where are the reboots? I dunno, perhaps you don't know what you're doing, and considering your humourous remark about access I'm pretty sure you really don't have a clue.
Never underestimate the relief of true separation of Religion and State.
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.
Big words, and I don't see any proof of it. In what way is the C# implementation of MS bad? (and others thus good?) Seems like you're recylcing a lot of hot air without adding anything useful to the conversation.
Never underestimate the relief of true separation of Religion and State.
Only baby programmers and script kiddies and VB wienies are afraid to handle pointers.
You've evidently never programmed anything of any size, a notion that is backed up by a quote on your webpage: "We're studying for our Masters Degrees in Computer Science at NSU and hopefully we'll be finished on June 20, 2002."
When you get out into the Big Bad World Of Real Employment(tm) you'll find that those cute little pointers that you're so fond of in your toy CS101 code have grown up into big, badly behaved monsters that will bite you at any opportunity.
If you're doing a project of any complexity, keeping track of all your data pointers becomes a non trivial problem - more so when you start working with several other people on the same codebase. What is the lifetime of an object? whose responsibility is it to see that that object is destroyed? How do these rules change under faliure conditions? How do you ensure that all the rules you've put down are obeyed?
Jeez, why do you think Smart Pointers have become increasingly popular?
The current episode of the .NET show is about exactly this. Well worth checking out if you want to be informed about such things.
Write a just-in-time compiler for an emulator. You can't do this in Java, or any other "secure" language that doesn't let you write directly to memory, access it via pointers, and use pointers to functions in that memory.
You will NEVER see fast, efficient emulators or just-in-time compilers written in any so-called "secure" language. Instead, you need a language like C, or assembler... or both.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
One of the most annoying aspects of java is that you can't do that. Java is the perfect lock-yourself-in language. If you want to escape, the only standard mechanism is JNI, which is completely useless (the verbosity and ease of failure when using JNI is mind-boggling, when I tried to use it a year ago, I eventually had to write a tool for generating JNI. What should have been a simple foreign function interface is really a complete mess.)
If C# offers mostly the same as Java, but with added features for real-world programming, such as the ability to add a dirty hack where it's needed, without going through all the torture and pain that Java makes you suffer, then I and many other developers will be much more happy to use C# than Java.
If all you care about is security, you wouldn't be using Java anyway, and you would certainly not download executable code over the web (applets). And if all you want is applets, then by all means, go ahead and use Java. But for people looking for something to use for enterprise-wide programming systems, having to integrate lots of legacy code, I'll bet C# will make a strong contender just because of this feature.
True, making it simple to do unsafe things is potentially dangerous. But making it unecessarily complex to do simple things also adds complexity, which isn't good for security either.