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."
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.
This space for rent.
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)
If you dumb-down any programming language, it becomes secure. The ultimate is basic BASIC (no pun intended). As long as you remove PEEK and POKE, you will have a completely secure system
10 PRINT "THIS IS A SECURE SYSTEM"
20 GOTO 10
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.
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.
"Until now, computer security has been reactive. Our defenses improve only after they have been successfully penetrated,"
After reading the dude's name above, did anyone else hear this as a B52's song?
Un-til NOW - computer security has been re - ACTive!...
Tell it Fred!
Excellent idea but won't work in the changing market.
Reason is the language can not do what Design is required to do. What ever scheme they come up with will only fall apart when the true requirements change. As systems change so will the language and since language needs to stay backwards compatible it will fail.
Much better to train people in proper Software Development with a Security focus. This is where, what ever language is chosen by the Project Manager the goal will be achieved.
what the security policies of java?
that have there own holes?
I just read about EROS last week . . . don't know how well it works, and it's probably old news to a lot of people. But the concept seemed interesting. EROS OS
just to run notepad
Microsoft's Windows Communication Foundation already support this...
According to the paper, Fabric is an extension of Jif:
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.
Not to be confused with the *other* development-related Fabric at http://fabfile.org/
...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 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 has a physical presence which can be subverted in amusing ways.
Then we have the users/devs/sysadmins that constitute another weak link.
Sounds a good idea though and the approach might be made to work down through the system. Perhaps it could be called Trusted Computing or something and would clearly need fronting by a consortium consisting of: AMD/Intel, Dell/HP/IBM,MS and Oracle - the fun loving group we can all trust to "Just Do It Right" (TM).
Someone once again managed to come up with a way to slap an additional ton of overhead on top of Java.
We're about to see Oracle go postal on the whole Java landscape, stay away from it.
I don't know about anybody else, but the first thing I thought of when I read TFS was SELinux. The only difference, really, is that instead of having the OS preventing various files from being accessed in insecure fashions, it prevents programs from doing insecure things to its own data. It's an interesting idea, but it's based on the assumption that you can't ever trust programmers to Do Things The Right Way. Of course, when you look at all of the buffer overflow exploits in Windows, it does begin to look like they're right but wouldn't it be better to teach proper programming technique in the first place?
Good, inexpensive web hosting
In fact it's so old even microsoft is using it.Code contracts + security policy coding is already present in .NET framework (code contracts being a separate download).
I'm pretty sure other languages have their own version as well.
This is fycking gay, slashdot. It sounds like the language "is in control".
Weaves Security Into Code, that sounds dingely goodie!!! No, really!!!
Must be true AI to take out the biggest security problem... the user.
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.
Am I part of the core demographic for Swedish Fish?
a) who cares? The JVM is fucking exploit-ridden anyway.
b) they're polishing a turd
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
The compiler enforces the security policies and will not allow the programmer to write insecure code.
Oh really? I'm an expert. I can write insecure code in any language. Guaranteed!
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.
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 hardware through the use of capability based hardware, such as the Plessy SS 20(?), the IBM Sword (not the newer IBM thing by the same name), the Intel 432, and other hardware that never saw the public light of day. (Those who funded these projects were not fond of the public limelight. and some of this work is not easy to find on the web.)
I did some papers about how one might build a debugging system for this kind of secure software - debugging tends to cut through security walls - but I have never seen those on the public net.
It's built on Java... so it is going to be bloated and have 45,000 libraries that do the same exact thing.
There are a few ways to do aspect-oriented programming, and having everything inherit from a common base class is one of the crappier methods of implementation. There's nothing new about security in there, either.
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/
Our homegrown SOA has security constraints at every initialization and every commit. The same conditions exist for the Entity layer as for the service, but are separately managed. Essentially, unless you explicitly make your service "non secured", you have to give it a role-hierarchy based graph of security constraints. We have a well-defined way of doing this, and it is a primary consideration of everything we add to the system.
That's not the same as "adding security to the language", but in my world it is much more relevant.
AOP is a means to the end for an architecture like this, but AOP is not in and of itself, the end result.
-fb Everything not expressly forbidden is now mandatory.
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?
That'll be broken before it's ever used. I can see it now fabrihax.rar.torrent fabrixcull.gz
The fabric language alone won't be targetted, the java platform will be, and since that's now maintained by Oracle (mediocre) fun will be had by all.
I wouldn'r go near "fabric" with a 25 ft. barge pole, but I could certainly see why minions.gov would want u to be suckered into it, for prostitute-grade easy access.
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 tree for universal changes across all that inherit from it.
--
make install -not war
Even a "true expert enterprise-grade programmer" doesn't necessarily know until the requirements are gathered, who gets to make what posts to the General Ledger, who gets to approve Sales Invoices at what levels, under what other business constraints, etc. This is the layer where enterprise security actually lives, and the only thing your programming language and runtime implementation can do is to assure you that when you do implement these constraints, there won't be any unknown back doors to get around the rules. (There will always be *known* back doors.)
Do people really expect their programming language to codify and enforce constraints like "third shift receiving manager may not accept shipments without an authorization XYZ..."
I expect a runtime environment to prevent that user from doing anything at all that could work around this kind of constraint. And, of course, template-driven web applications with business logic in Java on a well-secured server, with a database on a separate well-secured server, gets the job done just fine, and in an abundantly secure fashion.
(I realize the article refers to lower-level security in the context of parallel and distributed runtimes, which is something that I'm actually interested in, from an academic point of view. I took grad courses in parallel and distributed computing but this research has been of little to no use in the real world.)
-fb Everything not expressly forbidden is now mandatory.
"builds security into a program as its written". Doesn't Perl already do this? Security by obscurity.
Apple just deprecated Java. Sucks to be them.
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
The problem with security is ultimately not that people can't write secure code, it's that they don't even understand what to allow and forbid.
In different words, people are going to get the permissions and policies wrong; they are first going to make them too restrictive, and then when the system doesn't work, they are going to make them too permissive. Just like, you know, on operating systems, where every object already has policies and permissions associated with it.
this "will not allow the programmer to write insecure code" just like oracle was "unbreakable" and like "640k ought to be enough for anyone". Dumb programmers will find a way to make this insecure and smart programmers will be forced to in the worst way possible -- by having to implement workarounds in order to keep their jobs due to having to meet idiotic systems requirements.
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
"Hello, wo..."
"ACCESS DENIED - world does not accept greetings from unknown source."
I am anarch of all I survey.
the key statement in TFL is it 'makes security reasoning explicit and direct'. It addresses the software architecture problem that you mostly cannot reason confidently about the security of an application -- you cannot be confident that even a team of infallible programmers could produce a secure system because there is no way to exactly explain the right rules that would result in a secure system.
In this respect, application software architecture mostly lags behind network, OS and DB security architecture, where authentication and access control work in a way that allows for reasoning about the security, i.e. you can assert 'if this authentication and access control is implemented correctly then these resources will be secure, except from bugs in a lower layer of the architecture.'
Example: when you create user accounts on a *Nix or windows machine, you do not have to inspect all the applications on the system to confirm that none of them let user X access user Y's home directory. You can reason that the O/S's access control stops applications from doing that unless certain conditions are satisfied (eg user X is listed in the sudoers file).
This what you _can't_ do with most application software. An example : data driven applications which store data for thousands or millions of users will typically not create thousands or millions of DB logins each with controlled access. Instead, the application will use a single login for all users and rely on logic embedded in - and scattered throughout - the application code to stop user X seeing user Y's data. To verify "X cannot see Ys data" requires all the application data retrieval code to be inspected. All maintenance of this code risks introducing a leak.
This project appears to offer to close that gap in application security architecture. It's progress. Yes there are frameworks out there that address application level security, but having it embedded in the language is the right approach.
This has to bug me more than anything. All these "innovations" being created ... in {ug} JAVA.
Attention smart people at great institutions of higher learning ... go back to using C. The rest of the world can then re-use and improve upon your code.
Sheesh.
I'll bet the code is also self-documenting. And automatically enforces that it's used properly. So we can all breathe easier now that the problem of security has been solved.
Computer science loves to reinvent things. Haskell has this and this is an active area of research. Here is the original paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.5907&rep=rep1&type=pdf#page=185 (A library for light-weight information-flow security in Haskell)
It simply boggles the mind that some well intentioned, but woefully misguided Ph.D candidate gets the idea of his or her dissertation published as a usable program / Language Extension.
When will they learn that no amount of crap (This code) piled on top of crap ( Java interpreter ) piled on top of crap ( JVM ) piled on top of crap ( O/S ) piled on top of crap ( exploitable microcode) that the exploits are reflected all the way back to the top of the heap of crap and no matter how you dress it it is still a huge heap of crap!
Hey KID! Yeah you, get the fuck off my lawn!
...when you set up the right mailcap to convert it to text with w3m!
It makes people flip when they see their HTML email, MS Word attachments, and PDF attachments rendered into plain old text and displayed in mutt on my xterms.
Security through obscu^H^H^H^H^H lethargy
---------- ovidius naso
It could have tried to bill the card as a test tomake it work. I wish I was kidding... 19:00 forwards
This has to bug me more than anything. All these "innovations" being created ... in {ug} JAVA.
Or testing students programming skills using COBOL
The new right fascists are bilingual. They speak English and Bullshit.
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...
Perhaps you would rather look at Cyclone then?
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.
And how is Java secure?
I am not a robot. I am a unicorn.
It is bad netiquette to speak of spelling mistakes as the internet is an international place and the person you correct might not be a native speaker.
Ultimately, it is the patient who should control access to her medical information. This is the central tenet of privacy. Labeling Java classes with security markings won't work because you need the equivalent of row-level access policies. And, the row-label is usually: ask the patient. However, this approach doesn't scale. So, color me skeptical.
As a concrete alternative: What we need is a way for patients to specify their privacy expectations and for the system to enforce those expectations. This approach also requires good defaults, for example specified collaboratively by privacy advocates (favoring sharing limitations) and health care advocates (favoring information sharing for specific purposes).
Wasn't too clear from the site, but downloaded it and checked, oss and gpl 2, coolness!
They built the system on top of Java, and the language is similar to Java, but it is not really Java. It doesn't expose that much of Java and it has its own protocols for security policies, communication, serialization, and persistence. It looks like a node of Fabric could be implemented without using Java or the JVM at all.
Is this built into the compilation time and then just left alone, or is this another security layer that is checked each time you run your programs, thereby making an extremely slow language even slower?
Even if it has value they made sure this would never be used widely by releasing this under a GPL license. Same for Jif.
That ensures no one can use it for commercial purposes. In other words this is purely an academic exercise.
Doctors and lawyers can easily bring in double the salary of a software engineer because quality is top priority.. They have "mission critical" jobs.
Software engineering, OTOH, has seen a race to the bottom in terms of salary.
Why? Because quality is not top priority for software. Secure code is not seen as mission critical, and somehow programming is a lower-class job.
The software industry needs to wake up and recognize that software quality is mission critical, and can't be automated in the same way as manufacturing a car.. Writing good code requires talent and training, just like writing good contracts, researching case histories, diagnosing illness, or performing surgeries.
Bad code leads to bad things.. Crashed aircraft, stolen intellectual property, dead patients; everyone on slashdot knows these things. In 2002, the NIST concluded software bugs cost the US economy $59 billion annually. A 2007 IEEE paper concluded vulnerability announcements typically reduce a firm's stock price by 0.63% on the day of announcement. http://www.computer.org/portal/web/csdl/doi/10.1109/TSE.2007.70712
Try requiring similar levels of training and accountability from your programmers. Pay commensurate with that expertise.
The compiler enforces the security policies and will not allow the programmer to write insecure code
20% of PHBs will soon lose their jobs. Automated!
Those are front doors, numbnuts.
The ad pictured a brick wall, covered floor to ceiling with fire alarm bells. The caption was, "More security doesn't make you more secure."
include $sig;
1;