×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Programming Language Weaves Security Into Code

Soulskill posted more than 2 years ago | from the you-can't-goto-there-from-here dept.

Java 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

216 comments

Tall statement (1)

recoiledsnake (879048) | more than 2 years ago | (#34018260)

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:Tall statement (2, Interesting)

owlstead (636356) | more than 2 years ago | (#34018328)

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 (-1, Troll)

recoiledsnake (879048) | more than 2 years ago | (#34018386)

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).

If you read the title and summary, it talks about security, not secure programming.

Re:Tall statement (1)

owlstead (636356) | more than 2 years ago | (#34018892)

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 (0)

Anonymous Coward | more than 2 years ago | (#34018966)

uh... huhuhuh...

I have a "point" I'd like to "bare"...

huhuhuhuh

Re:Tall statement (4, Insightful)

Anonymous Coward | more than 2 years ago | (#34018420)

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:Tall statement (2, Insightful)

hedwards (940851) | more than 2 years ago | (#34018578)

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.

Re:Tall statement (0)

Anonymous Coward | more than 2 years ago | (#34018668)

So we are going to include companies like Red Hat or groups like GNU project as well, right? You aren't going to let them get away with publishing code with security problems either, right?

Re:Tall statement (0)

Anonymous Coward | more than 2 years ago | (#34018948)

Of course not. Only companies that sell their software (licenses) have to be held accountable for bugs in their code.

Corporations that don't want the liability then, will just have to move to a software-is-free-but-pay-through-your-nose-for-support model. In other word, Enterprise users pay the same, but the rest of us (minus the GNU/GPL purists) get some more free software.

Re:Tall statement (1)

owlstead (636356) | more than 2 years ago | (#34018828)

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:Tall statement (1)

arth1 (260657) | more than 2 years ago | (#34019100)

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:Tall statement (2, Insightful)

Monkeedude1212 (1560403) | more than 2 years ago | (#34018376)

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?

Re:Tall statement (4, Insightful)

h4rm0ny (722443) | more than 2 years ago | (#34018496)

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:Tall statement (2, Interesting)

Alain Williams (2972) | more than 2 years ago | (#34018840)

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:Tall statement (1)

h4rm0ny (722443) | more than 2 years ago | (#34019050)

Mutts nice, but I like to send HTML emails and last time I looked at it, that wasn't Mutt. If someone made something as lean and powerful as Mutt, with the HTML editing capabilities of Thunderbird (nowadays a bloated corpse of an email client), it would be my dream email client.

Re:Tall statement (0, Insightful)

Anonymous Coward | more than 2 years ago | (#34019124)

Mutts nice, but I like to send HTML emails

And I like to watch radio programs.

Re:Tall statement (0)

Anonymous Coward | more than 2 years ago | (#34018864)

In ten years time, we're going to be running our software on hardware five times as powerful

You're computer is only five times as powerful as one built a decade before it?

Re:Tall statement (1)

h4rm0ny (722443) | more than 2 years ago | (#34019096)

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 into saying the hardware is "more" or "less" powerful. It's different. Certainly it will be a lot more "powerful" when I'm compiling something. But it may not be as significant when I'm just running an application like Inkscape. Hard to say, really. Partly depends on how much advantage programmers take of multi-core programming. So that's why I was conservative with my estimates. I think my point has some (sarcastic) truth to it, but the numbers are guesswork.

Re:Tall statement (1)

jd (1658) | more than 2 years ago | (#34019028)

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 OS runs the same number of checks, just on different settings per class), and you get most of the benefit.

(The only difference is that their system would have each class running checks against other classes, which is unnecessarily bulky.)

Re:Tall statement (1)

Obfuscant (592200) | more than 2 years ago | (#34019244)

...you should be able to code it into the virtual machine and use the security labeling available in the native OS.

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 secure Perl compiler ever seen by man. It won't let nobody look at nothing they ain't authorized to look at", and then forget that all your data can be copied to a thumbdrive using 'cp' and displayed using 'od' (or maybe even vi!).

fad (0)

Anonymous Coward | more than 2 years ago | (#34019330)

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.

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.

Re:Tall statement (1)

Nutria (679911) | more than 2 years ago | (#34018550)

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 (2, Insightful)

master0ne (655374) | more than 2 years ago | (#34018702)

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.

Re:Tall statement (1)

pongo000 (97357) | more than 2 years ago | (#34018706)

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:Tall statement (1)

alanebro (1808492) | more than 2 years ago | (#34019006)

SELinux is/was intended for embedded applications and servers; things where the functionality is strictly defined. Using it on desktops, while indeed safer, was not the NSA's original intent. It is truly a nightmare to maintain on desktops when your installed packages are constantly changing.

Re:Tall statement (2, Insightful)

santiagodraco (1254708) | more than 2 years ago | (#34019002)

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.

Re:Tall statement (1)

Asclepius99 (1527727) | more than 2 years ago | (#34019070)

I find the quote about defenses only improving after it's been penetrated funny for a different reason. Fabric may be built to be more "secure", but it's going to work exactly the same way as any other language or program built with a language. More likely than not if Fabric becomes popular someone is going to figure out a way to exploit the code to do something it wasn't intended for and they'll have to some up with a way to solve that problem after the fact, just like everyone else. Isn't the reason that our defenses have to be proven inadequate at first usually because the people that either designed the language or used it to write a piece of software didn't know that the exploit possibly to begin with? I don't see how that's going to change.

Instead of a new language... (2, Insightful)

Nutria (679911) | more than 2 years ago | (#34018266)

they should have extended Ada.

Re:Instead of a new language... (1)

shutdown -p now (807394) | more than 2 years ago | (#34018436)

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:Instead of a new language... (1)

Nutria (679911) | more than 2 years ago | (#34018602)

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:Instead of a new language... (1)

shutdown -p now (807394) | more than 2 years ago | (#34018734)

Can you give some specific examples of how Ada is superior to Java in terms of security?

Re:Instead of a new language... (0, Troll)

BlackSnake112 (912158) | more than 2 years ago | (#34018924)

Ada was not an OO language at first. The compiler wanted to know everything at compile time. Which is why Ada if it compiled successfully, the program often ran. You may have not gotten the result you wanted, but the program ran without error. When Ada switched to OO it screwed a lot of things up. Why do you think the air traffic control systems took so long? The OO Ada was saying yes you can land your plane in the middle of a hurricane and 5 tornados. I knew some people working on the new control tower software. That was a serious problem.

Re:Instead of a new language... (0)

Anonymous Coward | more than 2 years ago | (#34018526)

they should have extended Ada.

Look, if you're that into pain, feel free to slam your dick in a car door all you want - leave the rest of the world alone.

Not that bad an idea (2, Interesting)

HiThere (15173) | more than 2 years ago | (#34019044)

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.

beat this (4, Funny)

heptapod (243146) | more than 2 years ago | (#34018278)

10 intpray "ellohay orldway"
20 otogay 10

For extra encryption use rot-13.

Re:beat this (-1, Troll)

Anonymous Coward | more than 2 years ago | (#34018308)

otogay 10

your code is gay

Re:beat this (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#34018380)

your mom is gay

Re:beat this (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#34018584)

Your face is gay

Re:beat this (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#34018704)

Your ass is gay

Re:beat this (2, Funny)

timboc007 (664810) | more than 2 years ago | (#34018880)

For extra encryption use rot-13.

And for extra-extra encryption, use it twice!

Re:beat this (0)

Anonymous Coward | more than 2 years ago | (#34019162)

This is the one time I wish I could mod Redundant as +1 instead of -1 ;-)

Why isn't this code working? (5, Insightful)

ak_hepcat (468765) | more than 2 years ago | (#34018310)

I -swear- i gave it the right permissions... well, i'll just turn on ALLOW:ANY and debug it..
Hey, that works.. well, it probably won't hurt to leave that there... :rinse :repeat

** yeah, like that'd never happen...

Re:Why isn't this code working? (2, Interesting)

Anonymous Coward | more than 2 years ago | (#34018922)

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? (4, Funny)

Anonymous Coward | more than 2 years ago | (#34019130)

I have a similar piece of code, give me the number and I'll check it against mine.

Re:Why isn't this code working? (1)

arth1 (260657) | more than 2 years ago | (#34019060)

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 what security is really needed.

It's called BASIC without PEEK or POKE (0)

Anonymous Coward | more than 2 years ago | (#34018316)

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

Re:It's called BASIC without PEEK or POKE (0)

Anonymous Coward | more than 2 years ago | (#34018428)

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

THIS IS A SECURE SYSTEM
THIS IS A SECURE SYSTEM
THIS IS A SECURE SYSTEM
[CTRL][BREAK]
#

Re:It's called BASIC without PEEK or POKE (1)

topham (32406) | more than 2 years ago | (#34018720)

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:It's called BASIC without PEEK or POKE (1)

interval1066 (668936) | more than 2 years ago | (#34018824)

"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:It's called BASIC without PEEK or POKE (1)

martin-boundary (547041) | more than 2 years ago | (#34019106)

10 PRINT "WHATS YOUR NAME?"
20 INPUT N$
30 PRINT "WHATS THE PASSWORD?"
40 INPUT P$
50 PRINT "HELLO EVERYBODY, ", N$, "'S PASSWORD IS ", P$
60 GOTO 50

Yawn (0)

Anonymous Coward | more than 2 years ago | (#34018318)

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.

Re:Yawn (2, Interesting)

adisakp (705706) | more than 2 years ago | (#34018400)

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:Yawn (1)

enderjsv (1128541) | more than 2 years ago | (#34018572)

Is that an indictment of bad programmers, or an indictment of copy-and-paste. Cause god know how hard life would be without copy-and-paste. Don't want to even imagine it.

Re:Yawn (1)

hedwards (940851) | more than 2 years ago | (#34018672)

The point is that certain mistakes shouldn't be made again. Many languages provide facilities for it. Sometimes it requires more drastic measures like deprecating a call and replacing it with something new. Not that I really understand the nuances, but there was that whole strlcopy() change in the past. It wasn't strictly speaking necessary, however it did cut down on a lot of mistakes that programmers would make.

It was from what I gather important enough that it's not just what the designers of Pascal did, it was added to others as well. Turns out that having a limit to the number of characters is a good thing.

I don't see it working for long. (4, Insightful)

Jason Pollock (45537) | more than 2 years ago | (#34018350)

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:I don't see it working for long. (1)

jd (1658) | more than 2 years ago | (#34019098)

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.

Fred Schnieder... (1, Funny)

Anonymous Coward | more than 2 years ago | (#34018354)

"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!

Nice Idea but long term will not work. (0)

Anonymous Coward | more than 2 years ago | (#34018382)

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.

Reminds Me of EROS (1)

matt_hs (1252668) | more than 2 years ago | (#34018406)

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 [eros-os.org]

and now ill go buy 80GB of ram (0)

Anonymous Coward | more than 2 years ago | (#34018430)

just to run notepad

WCF (0)

Anonymous Coward | more than 2 years ago | (#34018448)

Microsoft's Windows Communication Foundation already support this...

Based on Jif, not (directly) Java (1)

Lord Grey (463613) | more than 2 years ago | (#34018472)

According to the paper, Fabric is an extension of Jif [cornell.edu] :

Jif is a security-typed programming language that extends Java with support for information flow control and access control, enforced at both compile time and run time.

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.

BOILERPLATE ENTERPRISE-GRADE SOFTWARE SOLUTIONS... (1)

Suiggy (1544213) | more than 2 years ago | (#34018508)

...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 (1)

JSG (82708) | more than 2 years ago | (#34018530)

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).

Re:It only addresses on aspect of the whole (2, Interesting)

owlstead (636356) | more than 2 years ago | (#34019056)

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.

Nice (0)

Anonymous Coward | more than 2 years ago | (#34018534)

Someone once again managed to come up with a way to slap an additional ton of overhead on top of Java.

Java? No thanks (0)

Anonymous Coward | more than 2 years ago | (#34018568)

We're about to see Oracle go postal on the whole Java landscape, stay away from it.

This isn't a new idea, really. (1)

techno-vampire (666512) | more than 2 years ago | (#34018576)

I don't know about anybody else, but the first thing I thought of when I read TFS was SELinux. [wikipedia.org] 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?

Re:This isn't a new idea, really. (2, Insightful)

Raenex (947668) | more than 2 years ago | (#34019112)

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:This isn't a new idea, really. (1)

raddan (519638) | more than 2 years ago | (#34019116)

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 everyone needed to actually be a competent programmer in order to program, we wouldn't have this problem (I dispute this claim, BTW; I think good programming is simply the outcome of good design, but that good design is EXTREMELY difficult). But the barriers to entry in programming are fairly low. I would conservatively guess that most programmers are of the copy-and-paste from Google search results variety, and their code runs most of the time. The downside to this is obviously that most programs out there are shit. On the other hand, there are a lot of programs out there, and given the complexity of modern computers (do you really want the guy who's writing your medical records system to know about optimal register allocation-- REALLY?!), I think this is pretty astonishing. So safe programming systems are a huge benefit to everybody.

To answer your question in perhaps a more terse way: nobody really knows what "proper programming technique" is. I'm not talking about the Joel Spolskys of the world who *think* they know (and certainly, they have many real insights). I mean that we don't have any idea what constitutes a "good" program, except maybe some heuristics (hang around with Ruby people for awhile... you'll hear words like "beautiful" and "DRY"... but when pressed for technical definitions will get rather wishy-washy). This is a very active field in computer science, and the researchers we're talking about here run the gamut from language designers to educational researchers to CS theoreticians. Definitely an open question.

Re:This isn't a new idea, really. (1)

techno-vampire (666512) | more than 2 years ago | (#34019290)

(do you really want the guy who's writing your medical records system to know about optimal register allocation-- REALLY?!)

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 records system knew enough to do that.

Re:This isn't a new idea, really. (1)

owlstead (636356) | more than 2 years ago | (#34019146)

'... 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 security risks, I warmly welcome it. We could wait for the programmer to become bug proof, but that is like asking the user to understand OS security. It's just not going to happen (sorry).

Amazingly...this isn't new (0)

Anonymous Coward | more than 2 years ago | (#34018634)

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.

Re:Amazingly...this isn't new (1)

owlstead (636356) | more than 2 years ago | (#34019250)

"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 already existed... I know, I know, reading the article, unfair advantage.

FFS (0)

Anonymous Coward | more than 2 years ago | (#34018658)

This is fycking gay, slashdot. It sounds like the language "is in control".

...an extension to the Jav (0, Offtopic)

moxsam (917470) | more than 2 years ago | (#34018738)

Weaves Security Into Code, that sounds dingely goodie!!! No, really!!!

Code is not everything (3, Insightful)

gmuslera (3436) | more than 2 years ago | (#34018760)

Must be true AI to take out the biggest security problem... the user.

ho80 (-1, Troll)

Anonymous Coward | more than 2 years ago | (#34018818)

channel #gNAA On downward spiral.

Impossible to write insecure code? (1)

pedantic bore (740196) | more than 2 years ago | (#34018832)

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:Impossible to write insecure code? (1)

owlstead (636356) | more than 2 years ago | (#34019316)

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).

Even if it is magical snake oil... (1)

LSD-OBS (183415) | more than 2 years ago | (#34018842)

a) who cares? The JVM is fucking exploit-ridden anyway.

b) they're polishing a turd

Doesn't allow insecure code? (1)

Pedrito (94783) | more than 2 years ago | (#34018942)

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!

Did this in the 1970's (1)

karl.auerbach (157250) | more than 2 years ago | (#34019118)

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.

Re:Did this in the 1970's (1)

karl.auerbach (157250) | more than 2 years ago | (#34019134)

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.

nothing new, just AOP done badly (1)

PJ6 (1151747) | more than 2 years ago | (#34019214)

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.

object-capability security (2, Informative)

chocobot (715114) | more than 2 years ago | (#34019218)

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/ [elang.org]

Security first (1)

fishbowl (7759) | more than 2 years ago | (#34019286)

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.

It's not a language problem (1)

Sheik Yerbouti (96423) | more than 2 years ago | (#34019310)

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 (1)

Doc Ruby (173196) | more than 2 years ago | (#34019346)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...