Forgot your password?
typodupeerror
Java Programming Security

New Programming Language Weaves Security Into Code 216

Posted by Soulskill
from the you-can't-goto-there-from-here dept.
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."
This discussion has been archived. No new comments can be posted.

New Programming Language Weaves Security Into Code

Comments Filter:
  • 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)

      by owlstead (636356)

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

      • by Anonymous Coward on Monday October 25, 2010 @06:00PM (#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: (Score:3, Insightful)

          by hedwards (940851)
          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: (Score:3, Insightful)

            by ultranova (717540)

            Requiring companies to share even a portion of the expense when a vulnerability is exploited would do wonders for the situation.

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

        • by pixelpusher220 (529617) on Monday October 25, 2010 @06:19PM (#34018660)
          the old adage:

          Good, Fast, Cheap

          Pick any two.
        • by owlstead (636356)

          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.

          • by arth1 (260657)

            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.

        • by dudpixel (1429789)

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

        by ultranova (717540)

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

        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: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

      • by h4rm0ny (722443) on Monday October 25, 2010 @06:07PM (#34018496) Journal

        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)

          by Alain Williams (2972)

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

          • by h4rm0ny (722443)
            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.
            • 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

        • by jd (1658)

          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

          • by Obfuscant (592200)
            ...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 sec

      • by Nutria (679911)

        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: (Score:3, Insightful)

        by master0ne (655374)

        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

      • by pongo000 (97357)

        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

      • 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 th
    • what the security policies of java?

      that have there own holes?

    • by hyc (241590)

      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);}

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

  • by Nutria (679911) on Monday October 25, 2010 @05:50PM (#34018266)

    they should have extended Ada.

    • 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?

    • Not that bad an idea (Score:2, Interesting)

      by HiThere (15173)

      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

      • by Nutria (679911)

        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.

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

    by heptapod (243146) <heptapod@gmail.com> on Monday October 25, 2010 @05:51PM (#34018278) Journal

    10 intpray "ellohay orldway"
    20 otogay 10

    For extra encryption use rot-13.

  • by ak_hepcat (468765) <leif @ d e n a l i . net> on Monday October 25, 2010 @05:53PM (#34018310) Homepage Journal

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

      by Anonymous Coward

      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.

    • by arth1 (260657)

      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

    • by Aladrin (926209)

      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.

  • by Jason Pollock (45537) on Monday October 25, 2010 @05:56PM (#34018350) Homepage

    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.

    • by jd (1658)

      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.

    • by Tom (822)

      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

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

  • Naming Conflict (Score:2, Informative)

    by gomek-ramek (1340625)
    Not to be confused with the *other* development-related Fabric at http://fabfile.org/ [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 ha

    • Re: (Score:3, Interesting)

      by owlstead (636356)

      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

      • by plover (150551) *

        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

  • 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 lo
    • Re: (Score:3, Insightful)

      by Raenex (947668)

      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.

      • 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?

        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

        • by Raenex (947668)

          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.

          • The straw man, of course, was your introduction of "perfect programmers," which is something I'd never mentioned. If you can, and do make it a habit of using string copy functions that prevent buffer overflows, all well and good; if not, it's not a bad idea to use a language that requires you to specify how many bytes to copy. The important thing isn't what language you use, but that you write programs where buffer overflows can't happen.
            • by Raenex (947668)

              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

              • Please understand me: first, I'm not that interested in arguing with you and second, I don't think this is a bad idea. My original point was simply that it's similar in concept to SELinux. Yes, I realize that making a habit of using strncpy() instead of strcpy() isn't a Magic Bullet, but it will block the simplest forms of buffer overflow because it won't let you copy more bytes than the buffer will hold.
                • by Raenex (947668)

                  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.

    • by raddan (519638) *

      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

      • (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 r

      • by gbjbaanb (229885)

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

    • by owlstead (636356)

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

  • by gmuslera (3436) on Monday October 25, 2010 @06:28PM (#34018760) Homepage Journal
    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.

    • by owlstead (636356)

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

    • by c0lo (1497653)

      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.

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

    b) they're polishing a turd

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

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

  • It's built on Java... so it is going to be bloated and have 45,000 libraries that do the same exact thing.

  • People interested in this should also have a look at the E language. It is also a secure programming language. It goes a different route - there are no policies, instead a reference to an object gives the right to access the object. This works because there is no global access to objects. They call it object capability security. There is also a java compiler addon to enforce capability security. The relevant website is http://www.elang.org/ [elang.org]
  • 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?

  • 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

  • Apple just deprecated Java. Sucks to be them.

  • Snakeoil (Score:5, Interesting)

    by A beautiful mind (821714) on Monday October 25, 2010 @08:11PM (#34019688)
    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. [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.
    • by Tom (822)

      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)

      by Just Some Guy (3352)

      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

  • by ignavus (213578) on Monday October 25, 2010 @09:00PM (#34020062)

    "Hello, wo..."

    "ACCESS DENIED - world does not accept greetings from unknown source."

"Consequences, Schmonsequences, as long as I'm rich." -- "Ali Baba Bunny" [1957, Chuck Jones]

Working...