Slashdot Mirror
New Programming Language Weaves Security Into Code
Ponca City writes "Until now, computer security has been reactive. 'Our defenses improve only after they have been successfully penetrated,' says security expert Fred Schneider. But now Dr. Dobb's reports that researchers at Cornell are developing a programming platform called 'Fabric,' an extension to the Java language that builds security into a program as it is written. Fabric is designed to create secure systems for distributed computing, where many interconnected nodes — not all of them necessarily trustworthy — are involved, as in systems that move money around or maintain medical records. Everything in Fabric is an 'object' labeled with a set of policies on how and by whom data can be accessed and what operations can be performed on it. Even blocks of program code have built-in policies about when and where they can be run. The compiler enforces the security policies and will not allow the programmer to write insecure code (PDF). The initial release of Fabric is now available at the Cornell website."
they should have extended Ada.
"I don't know, therefore Aliens" Wafflebox1
10 intpray "ellohay orldway"
20 otogay 10
For extra encryption use rot-13.
I -swear- i gave it the right permissions... well, i'll just turn on ALLOW:ANY and debug it.. :rinse :repeat
Hey, that works.. well, it probably won't hurt to leave that there...
** yeah, like that'd never happen...
Support FSF: Stop thinking with your wallet, and think with your imagination. (cc/non-commercial)
Yes, and it does not prevent burglary either. If you mess up the transport & application protocol you are in trouble, but what has that to do with secure *programming*? Christ, I bet you can make programs with it that display your password in 10 feet high numbers as well (given a large enough monitor).
As experience teaches us, the first thing that people who need to share do is "chmod -R a+rwx ."
So, any security which requires signing of code to run will become looser and looser over time as problems are encountered. That bug is causing problems in production and it takes a week to validate and sign it? Loosen the validation to get it to 15mins, or turn it off completely.
That sounds more like it would get in the way - perhaps I've come up with a more secure and robust algorithm than they've thought of and all it requires is a bit of data transfer from one section to another - but its deemed insecure due to their constraints - even though I've handled security in a different section.
On top of that - his initial statement basically makes no difference:
Our defenses improve only after they have been successfully penetrated
So you expect all programmers to switch to Fabric just overnight? Who's going to go through the hassle of learning a new language for security reasons if you haven't had any security reasons already? It's like - if I am concerned with security - it'll already have made its way into the code. If I'm not concerned with security - why would I go learn Fabric?
Yet another programming language aimed at making it easier for novice programmers to do the right thing by protecting against the mistakes that novices have made in the past.
The problem is that past mistakes are not a predictor of future mistakes.
I know some less gifted programmers who code primarily by copy-and-paste. In that group, past mistakes are a very good predictor of future mistakes.
Secure software development takes longer to develop. That is the primary reason it is not widely practiced. Unless this new language makes secure programming as quick as unsecure programming, then corners are always going to be cut and security will suffer.
Not to be confused with the *other* development-related Fabric at http://fabfile.org/
it's deemed insecure due to their constraints - even though I've handled security in a different section.
Yep - sounds like more bloat to me. In ten years time, we're going to be running our software on hardware five times as powerful as that which we use today and the software will do the same things it does today no faster.
And then some old person will implement an email client in C using only the oldest and slimmest of libraries and everybody's heads will explode with shock at the speed of it.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Assuming that out side forces are never brought to bear. Until companies are held accountable for exploits in their code it's not going to change. Requiring companies to share even a portion of the expense when a vulnerability is exploited would do wonders for the situation.
the old adage:
Good, Fast, Cheap
Pick any two.
People in cars cause accidents....accidents in cars cause people
You would switch to fabric if you are concerned with security, eventhough it will have found its way into your code without fabric, the point is fabric is security oriented making it HARDER to do insecure things. On top of that it would seem your argument about coding your own mechinism being deemed insecure, im sure that would be a user error as opposed to a problem with the language itself as there has to be a mechninsm to specify what is and is not to be trusted within the language, if you wish to do such things to mark the system you need trusted as trusted? and finally, no i wouldnt expect people to adopt fabric overnight, just like they didnt adapt java, python, or php overnight, however one thing is certin, they will never adopt it if it does not exist. As far as the learning curve associated with it, its basically java, you just need to learn some new modules etc, syntax should be very javaish.... keep in mind this is aimed at large networks that may or may not have a central security authority, its ment to help developers of large networks (like facebook) design more secure and robust systems from the ground up, while providing a extra layer of "security". Im sure if you try hard enough you can manage to break it, as everything is only secure as it is accessable, someone somewhere will break it if they want to.
Noone writes jokes in base 13!
Must be true AI to take out the biggest security problem... the user.
And then some old person will implement an email client in C using only the oldest and slimmest of libraries and everybody's heads will explode with shock at the speed of it.
They already have and I use it, it is called mutt.
Your response doesn't give any reasons for not using Fabric other than maybes and what ifs that may or may not apply to anyone including yourself. You might as well say "why in the world would I ever use Fabric, I live in a log cabin and forage for food, it makes no sense!"
Also who said they expect all programmers to switch to Fabric AT ALL let alone over night? It's a choice. They are offering a potential solution for java based systems that can, in their opinion, improve the overall security of the system by embedding secure rule sets into the code itself, something that has not been done as a part of the language before.
And as for his statement about "our defenses improving" it makes perfect sense and it's at the heart of what is wrong with systems today. Security is often treated as a secondary concern until someone breaks in, then it's top of mind and only then is it implemented properly.
It's irresponsible to act as if security is a given. It's also absurd to think that simply because someone is concerned with security that that means they are therefor implementing secure systems or even have the capabilities to do so.
Now, is Fabric good? Who knows, only time will tell.
They'd have needed to make unbounded string the default literal character type, and given it a better name. Say, just "string". They'd have needed to make it easier to use the heap. Garbage collection would need to be built-in (optionally disableable) rather than optional, and never implemented.
And they should start from the Spark subset of Ada.
But Ada won't ever go anywhere, and wishing it would is futile. It's been purposed to the embedded systems market, and it's not likely to change.
O, they should also define a built-in B+Tree data-type. (Generic, so it could be adapted to the particular types that you want to work with.)
A problem is in the GUI. If you allow C callbacks you don't have a secure system. If you don't, you need to maintain your own GUI system. And it will never look like the other systems. Probably this would mean you need to partition the compilation into secure modules and non-secure modules. (Allowing you to call C libraries eases all kinds of problems...but it's death on a secure system. This means that you need to be able to partition things into parts that you can't really trust, and parts that you can.)
It's a pity this is a waste of speculation, because it's not going to happen. Most people hear the term Ada and they think of scare stories, not realizing how much worse C++ is than Ada ever was in terms of complexity and difficulty to master.
I think we've pushed this "anyone can grow up to be president" thing too far.
They partition it into several pieces so that you have modular access conditions. Java is already build in such a way that you cannot directly access the hardware - you can just run byte code. Of course, there may be bugs in native libraries or in the byte code execution, but that is a rather small attack surface. Basically, that's always what you try to do; you limit the exposure of security relevant features. There will of course still be bugs, but they should be much more localized.
Building this on C++ would not make sense, since you cannot have modular security if your application logic runs in a single memory space. The only things you can do against that is trying to mitigate the fact that you *do* have access. Examples of mitigating that are the non-execute bit, random memory layouts with "no-go areas" and static analysis of code.
So sure, there may still be holes. But I may at least be sure that that bug in the TCP socket library is not exposed to the part of the code that verifies user input, or badly written code in library X.
Because trying to force everybody to use Ada worked so well...
but wouldn't it be better to teach proper programming technique in the first place?
Good God, no. How much failure do you need to see in the real world before you guys stop with this old saw about improving or hiring perfect programmers? Programmers are people, and they make mistakes, even the best of them. Any tool that helps automate away common mistakes is a good thing.
People interested in this should also have a look at the E language. It is also a secure programming language. It goes a different route - there are no policies, instead a reference to an object gives the right to access the object. This works because there is no global access to objects. They call it object capability security. There is also a java compiler addon to enforce capability security. The relevant website is http://www.elang.org/
Give me TP for my security hole!
Turbo Pascal?
The language is either not Turing complete and then mostly useless for practical general computing, or it is Turing complete and then it provides no real security.
It might avoid some class of problems, but it will never free a programmer from having to clarify his/her intentions. Security is an abstraction-level free problem, meaning that it equally can be an issue at the x86_64 instruction set level and also at the level of high level contractual/social agreements that code has to handle.
As Bruce Schneier said long ago: Security is not a product; it's a process.
Security is also a tradeoff between a system being secure and usable. You can make things more secure by allowing a system to do less. I'm not saying that this new programming language is useless, but it all comes down to a careful description of the language. If the creators advocate it as a secure programming language that makes code written in it secure by default, then they are almost certainly wrong and will quickly become a laughingstock. On the other hand, if they market it as a language that avoids or makes it impossible to commit certain classes of security problems, as a language that pays attention to it's core code for security issues and as a language that makes it clear security is a mindset, then I see it being useful.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
I'll take my cars good and fast, and my women fast and cheap, thanks.
"Hello, wo..."
"ACCESS DENIED - world does not accept greetings from unknown source."
I am anarch of all I survey.
And thus the claim "The compiler enforces the security policies and will not allow the programmer to write insecure code" is shown to be rubbish.
This thing may or may not help security, but claiming it won't let you write insecure code is pure marketing bullshit; Slashdots or Cornells, now that's a question.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Yeah: since the expense is potentially unlimited, it would become far too risky for any mere mortal to write code, thus leaving only the large companies that can duke it out in a court willing to do that. I can feel Microsoft drooling...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Oh, so you're one of those people I hate who keep sending me HTML emails.
Nah, I'm pretty sure everyone on my email list is living in the 21st Century by now. :)
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Come on Java guys, .NET has had a policy framework for years! It's called Code Access Security, It's what prevents WPF browser applications accessing most of your pc. applications run from internet zones are denied access to environment variables even.