New Programming Language Weaves Security Into Code 216
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."
Tall statement (Score:2)
The compiler enforces the security policies and will not allow the programmer to write insecure code
Even if it works perfectly, it will stop only a small subset of insecure code. For example, this tool would do absolutely zilch to stop the attack like FireSheep on Facebook.
Re: (Score:3, Interesting)
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).
Re:Tall statement (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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...
Re:Tall statement (Score:5, Insightful)
Good, Fast, Cheap
Pick any two.
Re:Tall statement (Score:4, Funny)
I'll take my cars good and fast, and my women fast and cheap, thanks.
Re: (Score:2)
the old adage:
Good, Fast, Cheap
Pick any two.
Which two are Linux?
Re: (Score:2)
Good and fast obviously. Do you realize how many paid man-hours have gone into the linux kernel? It's been anything but cheap.
Re: (Score:2)
Well, it will maybe bring down the barrier. And don't forget that insecure software costs loads of money. Maybe not in front then certainly later during the maintenance cycle. Of course, if you are able to charge for maintenance hours, you may be in luck.
Secure software may make a lot of sense for core security components. Proving that something is secure can be hard, any software that will bring that cost down is very welcome. If this is required depends on the type of software of course.
Re: (Score:2)
Well, it will maybe bring down the barrier.
Or raise the barrier to those who understand the policies -- the rest will be writing crappier code than ever, because they think that their ill-written policy will protect them so they won't have to think security anymore.
Re: (Score:2)
... Unless this new language makes secure programming as quick as unsecure programming, then corners are always going to be cut and security will suffer.
Its insecure programming. sheesh...
Re: (Score:3, Insightful)
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.
Re: (Score:2)
That is maybe, but *you* don't.
Of course, security is about secure systems and this programming language won't fill all the gaps, but you hardly have to remind Slashdot of that.
But maybe I'm confused and you have an interesting point to bare?
Re:Tall statement (Score:5, Funny)
Give me TP for my security hole!
Turbo Pascal?
Re: (Score:3, Insightful)
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 langu
Re:Tall statement (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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 [mutt.org].
Re: (Score:2)
Re: (Score:2)
you might want to look at Eudora OSE [mozilla.org] it is somewhat leaner than Thunderbird 3 but it is not as spartanish as mutt
Re: (Score:3, Insightful)
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. :)
Re: (Score:2)
It's essentially mandatory access controls at the object level. In which case, you shouldn't need to add it to the language syntax - you should be able to code it into the virtual machine and use the security labeling available in the native OS. The security would then be scripted as data, rather than hard-coded, allowing any existing program to gain this security with no modification to the code, merely a suitable XML file with the MAC labeling data. Minimal bloat, the speed should be unaffected (since the
Re: (Score:2)
No, this REQUIRES the native OS to cooperate to be successful.
According to the summary, the security policy is enforced by the COMPILER. That means if you change the access policy to a data file, you need to RECOMPILE all the code that touches that data, since the access is compiled in. At least, if the summary is correct, you do.
Further, this is like saying "I'm going to build the most sec
Re: (Score:2)
You're computer is only five times as powerful as one built a decade before it?
I was trying to extrapolate where I think things are going. I don't know how much further we're going to go in terms of sheer processor speed. Less far in the next ten years in terms of multiples of what has gone before, than in the previous ten years. There might be some revolutions that lead to much faster computers in the areas where that's needed (scientific computing, perhaps) but less likely in general public computers. We're probably going to see increases in cores and that doesn't translate as well
Re: (Score:2)
So you expect all programmers to switch to Fabric just overnight?
All the programmers who want to work on the DOD contract that specifies that the work be implemented in Fabric...
Re:Tall statement (Score:5, Funny)
Because trying to force everybody to use Ada worked so well...
Re: (Score:2)
Because trying to force everybody to use Ada worked so well...
They were Ada up.
Re: (Score:3, Insightful)
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 suc
Re: (Score:2)
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.
Much like SELinux. At some point, the security aspects are frustrating enough that you just turn the damn thing off.
Re: (Score:2, Insightful)
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 s
Re: (Score:2)
what the security policies of java? (Score:2)
what the security policies of java?
that have there own holes?
Re: (Score:2)
My compiler will allow you to write whatever code you want, but it will refuse to compile it into insecure code.
My compiler's source:
main(){exit(1);}
80/20 (Score:2)
If a hard had can save live in 80% of building side accidents is it not worth it?
Would you refuse to wear it out of sympathy for the 20% of cases where did not work out?
Mind you, some building side worker do precisely that...
Instead of a new language... (Score:3, Insightful)
they should have extended Ada.
Re: (Score:2)
They didn't do a language from scratch - they extended Java (c'mon, it's even in TFS). Why would Ada be any better here?
Re: (Score:2)
Re: (Score:2)
They didn't do a language from scratch
Yes, you're right.
they extended Java
That doesn't obviate my point that they should have extended an OO language that's already more secure than Java.
Re: (Score:2)
Can you give some specific examples of how Ada is superior to Java in terms of security?
Re:Instead of a new language... (Score:5, Funny)
Ada if it compiled successfully, the program often ran.
Well, that's not such an impressive achievement, given that Perl would often happily run something that you wouldn't ever think could compile.
The problem is to make sure that, when it runs, it does what the person who wrote the code intended it to do...
Not that bad an idea (Score:2, Interesting)
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 a
Re: (Score:2)
But Ada won't ever go anywhere, and wishing it would is futile.
Just like COBOL, the best Domain-Specific Language for writing financial apps.
Re: (Score:2)
Some companies already do. Java is more popular in the enterprise market, though, while Ada is more popular in the embedded market.
beat this (Score:4, Funny)
10 intpray "ellohay orldway"
20 otogay 10
For extra encryption use rot-13.
Re: (Score:2, Funny)
For extra encryption use rot-13.
And for extra-extra encryption, use it twice!
Re: (Score:2, Funny)
YODASIC:
"World, hello" 10 prints
to 10 go, line 20 tells
Why isn't this code working? (Score:5, Insightful)
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...
Re: (Score:2, Interesting)
Unfortunately, you're 100% right. I had a somewhat similar system just occur where a library for processing credit cards has an option to check the card to make sure it's valid before even trying to process it. Well, using my personal card as a test it said it was invalid. Take that check out and it works perfectly, so I'm not sure what it is actually checking, according to the docs everything required was there, but what should have been a useful feature just gave me a false negative, so I can't trust it.
Re:Why isn't this code working? (Score:4, Funny)
Re: (Score:2)
Considering that many of the people who are going to write this are the same who think that 0777 is a good permission for files and directories, I say that it's a given that this won't be too useful.
Security comes from a mindset, not from more tools.
Sure, tools can be helpful, but only in the hands of those who understand how the tools work, how to use them and the technical reasons why they use them. Else it will only instill a false sense of security, and may very well make the devs skip the analysis of
Re: (Score:2)
That is an example, but here's one that will be more common:
Programmer: I can't get X to work. Why won't it?
Community: Your security policies won't let it. You'll have to change them to allow it.
Tada.
I don't see it working for long. (Score:5, Insightful)
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.
Re: (Score:2)
You are correct. Actually, strong languages like Occam-Pi are better for security as the security is largely a product of making things much more specific. It is ambiguity that allows a lot of bugs to creep in.
Re: (Score:2)
As experience teaches us, the first thing that people who need to share do is "chmod -R a+rwx ."
Which is why I believe for a company, there is only one path to security - a combination of upper management understanding that security is important or they, not some lowly cubicle worker, could be out of a job, and Mandatory Access Controls.
"People" shouldn't even be allowed to determine the permissions of a file. And they absolutely should not ever be able to change the "a" value, which should be hardcoded to 0 everywhere. Remember "default deny"? We'd not dream of having firewalls like that, but our fil
Based on Jif, not (directly) Java (Score:2)
According to the paper, Fabric is an extension of Jif [cornell.edu]:
Fabric adds distributed programming and transactions.
Pretty cool stuff, even if it doesn't work everywhere and under all circumstances right now. It would be interesting to see how this kind of design matures.
Naming Conflict (Score:2, Informative)
BOILERPLATE ENTERPRISE-GRADE SOFTWARE SOLUTIONS... (Score:2)
...FOR ALL OF YOUR SECURITY NEEDS.
Because we all know how much fun it is to write software like true EXPERT ENTERPRISE-GRADE PROGRAMMERS.
It only addresses on aspect of the whole (Score:2)
It sounds good but it only addresses one security aspect of a system. It runs on top of Java which I seem to recall is blessed with a few bugs - how do they avoid those including all the ones that will appear in future versions.
Then the Java stack sits on top of a OS and that is a massive "attack surface" or whatever is the current bullshit from the consultants (OK that includes me)
Then the OS sits on top of some sort of hardware with its own built in software (BIOS etc) problems.
Then the machine itself ha
Re: (Score:3, Interesting)
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++ w
Re: (Score:2)
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.
You may be sure of nothing. You may have increased confidence in resistance of your software to flaws, but there's always a set of very clever attackers who are constantly defeating these kinds of security measures: discovering new, untapped flaws in old software; or discovering new, untapped flaws in the users pushing buttons on your systems.
For an example of why you still need to worry even if your OS supports the NX bit, see Return Oriented Programming [wikipedia.org]. And ROP can be coded to use an application vulnerab
This isn't a new idea, really. (Score:2)
Re: (Score:3, Insightful)
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.
Re: (Score:2)
Where did you get that strawman from? I never wrote anything like that! I'm talking about simple things, such as using a function that only copies a specified number of bytes into a buffer instead of one that copies everything so that you can't overrun your buffer. Making that a habit doesn't make you a perfect programmer and it doesn't prevent any and all bugs but
Re: (Score:2)
I don't see any straw man. Tripe about "trust programmers to Do Things The Right Way" and "teach proper programming technique" when it comes to buffer overflows is the same old shit we've been hearing for years from C programmers. It's much better if the language makes it impossible to have a buffer overrun, or in regards to the current article, to violate security policies.
Re: (Score:2)
Re: (Score:2)
I said "improving or hiring perfect programmers", because while you didn't say perfect, your message about "trusting" the programmers and educating them is part of the same old message from C programmers that these mistakes can be eliminated with sufficiently educated/good programmers. To prevent all buffer overflows, programmers need to be perfect.
No, just using something like a strncpy is not good enough. Even that requires the programmer to get the n right, and there are many, many places buffer overruns
Re: (Score:2)
Re: (Score:2)
First: If you're not interested in arguing, then don't. It takes two.
Second: Your original point was, besides comparing to SELinux, to question the whole idea by instead trusting programmers and teaching them. And it was exactly this tired old saw I was responding to.
By all means, if you're going to code in C, teach best practices, but it's a band-aid at best.
Re: (Score:2)
wouldn't it be better to teach proper programming technique in the first place?
The thing is, people have been saying that for years. Every iteration of the programming system, whether it be automatic program correction, garbage collection, references-that-are-not-pointers, object-orientation, modularity, high-level programming, type systems, virtual memory, or whatever other language abstraction designers have come up with, there's always been some crusty old programmer in the back of the room shouting about how "kids these days should just learn how to program."
And maybe if every
Re: (Score:2)
I realize that you intended this as a rhetorical question, but I'm going to answer it anyway. I don't care if that guy (or gal) knows about optimal register allocation, but I agree that it shouldn't be required for such a task. Still, writing code that minimizes the chance of buffer exploits or other common security issues isn't that hard, and I'd hoe that whoever wrote my medical r
Re: (Score:2)
do you really want the guy who's writing your medical records system to know about optimal register allocation
no, but I want him to know more than 'I click the wizard and it says "what parameters do you want", and I fill it in, and then I have a running web service'.
Re: (Score:2)
'... you can't ever trust programmers to Do Things The Right Way"
I do development as well, and you can *bet* I don't ever trust programmers to do things the right way - including myself. The trick is to minimize exposure of the system and limit the severity of the bugs.
Java is only so so. For instance, it does offer memory protection between classes, but it is not as modularized as it should be, and you do have many mutable and non-thread safe constructs (e.g. Java byte array).
If this language can minimize
Code is not everything (Score:4, Insightful)
Impossible to write insecure code? (Score:2)
Really?
That would be quite a breakthrough, but I am skeptical. Depending on policy-based security requires that you also have a language for policies that make it impossible to write bad policies.
I'd be thrilled with a programming language that makes it easy to write secure code, much less a language that makes it impossible not to.
Re: (Score:2)
Yeah, well, that claim is neither in the introduction or in the conclusion. Actually, the word "impossible" does not seem to be present *anywhere* in the paper, so we may safely assume that that is another gross Slashdot overstatement (actually the article is about data access within a development model / runtime system, so you may even state that it is plain BS).
Re: (Score:2)
Depending on policy-based security requires that you also have a language for policies that make it impossible to write bad policies.
See, that's a good example of some sports very dear in the Corporate Olympic Games: blame-shifting (you need stamina) and finger-pointing (a game of speed). The software engineer is in a much better position now to win these games - bad policies is what happens at deployment/admin time.
Even if it is magical snake oil... (Score:2)
a) who cares? The JVM is fucking exploit-ridden anyway.
b) they're polishing a turd
Doesn't allow insecure code? (Score:2)
Oh really? I'm an expert. I can write insecure code in any language. Guaranteed!
Did this in the 1970's (Score:2)
Back in the 1970's at System Development Corporation (SDC) in conjunction with groups at SRI, RSRE (in the UK), and elsewhere we were doing a lot of work on provably correct systems, including operating systems.
(The notion of "correct" was limited to a security criteria - a correct box did not need to work, only that it met the security criteria.)
We used languages such as Ina Jo and Pascal filled with lots and lots of formally shaped assertions about explicit and side effects.
This was moved down into hardwa
Re: (Score:2)
I forgot to mention that a lot of work was based on Jerry Popek's UCLA Data Secure Unix.
Data Secure Unix was amazingly slow. We could type the "date" command into the shell and when we got back from lunch it would be done telling us what time it was.
Java? (Score:2)
It's built on Java... so it is going to be bloated and have 45,000 libraries that do the same exact thing.
object-capability security (Score:2, Informative)
Re: (Score:2, Informative)
It's not a language problem (Score:2)
Yeah here's a tip the reason there is a lot of insecure code out there is that there are a lot of programmers out there that think that security problems are overstated and a bunch of hype. That's one of the reasons there are so many problems they think they have it all figured out when they clearly don't. They think security just slows them down and gets in their way. So how are you going to get this recalcitrant bunch to use the super secure language?
Rerooted Inheritance (Score:2)
I'd love to be able to use existing class libraries (like JDK), because I know them and there's lots of existing software dependent on them, but add features like these in Fabric to that class hierarchy. By making the existing Class Object inherit from something with those new features, like Class SecureObject. Then satisfy all the requirements of the newly featured objects in all the source code that calls the class library. But I don't see any way to insert other classes deeper towards the root of a class
Poor Apple... (Score:2)
Apple just deprecated Java. Sucks to be them.
Snakeoil (Score:5, Interesting)
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. [schneier.com]
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.
Re: (Score:2)
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.
You say that based on what analysis?
Sure, a programming language alone will never bring you 100% perfect security. Neither does any other system, method or tool. Sure you and I can write great, safe code in C. But the large majority of programmers has too little experience, doesn't care all that much, and is under perpetual time pressure to deliver functionality. The choice of language can dramatically change the quality and security of your code.
And, without having studied it in detail so far, from what I
Re: (Score:3, Interesting)
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 doesn't have to be all-or-nothing, though. You could make a similar argument about the usefulness of ACLs or Unix permissions or virtual memory: "these won't fix everything!" And yet all of those do make our systems more secure, and we certainly wouldn't want to get rid of them just because they're not perfect.
Speaking of ACLs - you could bolt something like that onto an existing language pretty easily. Imagine a "hardened Python" (that's what she said!) that runs in a Java-like sandbox with no access to
A secure language (Score:5, Funny)
"Hello, wo..."
"ACCESS DENIED - world does not accept greetings from unknown source."
Re: (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Also, if you are copying-and-pasting code several times, it's almost always better to make a function (or inline function, or macro, or template) so that if there is a bug in the code, then fixing it once fixes it everywhere it's used.
Given those facts, I'd say that it's a combination of bad programmer
Re: (Score:2)
Re: (Score:2)
It was from what I gather important enough that it's not just what the designers of Pascal d
Re: (Score:2)
PEEK, POKE, SYS
Probably a couple others in particular dialects. (LOAD, as implemented on Commodore is an issue as well).
Really, BASIC isn't even close to secure by default.
Re: (Score:2)
"As long as you remove PEEK and POKE, you will have a completely secure system..."
Absolutely wrong. If the language implementation doesn't include run-time buffer overflow checking, which is often overlooked in high-level languages and really can't exist in lower level ones, you've got an attack vector. Directly peeking at and poking into memory locations is only .01% of the battle. What if you want to use your "secure" basic as a cgi? Now you're got a whole new bushel of issues. The most secure language still has to contend with the problem of unintended consequences unintended uses.
Re: (Score:2)
20 INPUT N$
30 PRINT "WHATS THE PASSWORD?"
40 INPUT P$
50 PRINT "HELLO EVERYBODY, ", N$, "'S PASSWORD IS ", P$
60 GOTO 50
Re: (Score:2)
OH SHI...
Re: (Score:2)
"Fabric integrates many ideas from prior work, including
compile-time and run-time information flow, access control,
peer-to-peer replication, and optimistic transactions. This
novel integration makes possible a higher-level program-
ming model that simplifies reasoning about security and con-
sistency. Indeed, it does not seem possible to provide a high-
level programming model like that of Fabric by simply lay-
ering previous distributed systems abstractions."
Gosh, it is almost like they know that those things a