Slashdot Mirror

← Back to Stories (view on slashdot.org)

DARPA Open Source Security Helped FreeBSD, Junos, Mac OS X, iOS

Posted by Soulskill on from the also-juliennes-fries dept.

An anonymous reader writes "In a February 2013 ACM Queue / Communications of the ACM article, A decade of OS access-control extensibility, Robert Watson at the University of Cambridge credits 2000s-era DARPA security research, distributed via FreeBSD, for the success of sandboxing in desktop, mobile, and embedded systems such as Mac OS X, iOS, and Juniper's Junos router OS. His blog post about the article argues that OS security extensibility is just as important as more traditional file system (VFS) and device driver extensibility features in kernels — especially in embedded environments where UNIX multi-user security makes little sense, and where tradeoffs between performance, power use, functionality, and security are very different. This seems to fly in the face of NSA's recent argument argument that one-size-fits-all SELinux-style Type Enforcement is the solution for Android security problems. He also suggests that military and academic security researchers overlooked the importance of app-store style security models, in which signed application identity is just as important as 'end users' in access control."

22 comments

  1. DARPA yeilds advancements in many categories by Anonymous Coward · · Score: 1

    This is a nice and relevant example to /., but aren't there plenty of other examples where DARPA has ultimately benefited people other than the military? Like say.. the ARPAnet lead to the Internet, or mainframes to cloud computing, or virtual reality to video games, or onion routing to TOR. I know there are plenty of smarter /.ers who can think of a bazillion more examples.

    1. Re:DARPA yeilds advancements in many categories by um...+Lucas · · Score: 3, Insightful

      Yes. The list is too long to even bother to post. But I'd wager most of what we take for granted, generally and technologically specifically, has its roots in public spending. If it wasn't publicly funded research projects that brought the technology to a state usable by private enterprise, or public money creating a market and demand for products that no one else could afford, our world would be vastly different today, and lacking in a lot. This is why I shudder at people who say that our government spending is the problem. Couldn't be further from the truth.

  2. NASA/DARPA and making the world better - openness by aisnota · · Score: 2

    The model had to be driven by someone, in this case DARPA or other contributors pushed ahead to validate it.

    Then more importantly, opening it up for adoption as much in science gets built upon.

    Right now our economy would be even better if more were declassified, made open as possible, read NASA in its ideal and spun out to create more jobs/technologies/societal benefits.

    If only the US would also advertise this as a contribution it makes all the time in the world to some less open societies, we would really be happening!

    Oh yes, you would probably have a higher paycheck and we could discuss real vacations for the ordinary citizen too.

    --
    http://www.aisnota.com/slashdot/ Welcome to Logic and the Future
  3. Excellent. by buttfuckinpimpnugget · · Score: 1

    So the wars have been worth it after all!

  4. SELinux != UNIX multi-user security by unrtst · · Score: 2

    SELinux and "UNIX multi-user security" are not referring to the same thing. This doesn't "fly in the face" of anything. I'm 99.9% sure "Unix multi-user security" is referring to user/group/world permission bits per file/directory. That doesn't help all that much in the realm of embedded systems, as they said. SELinux is an entirely different beast, and achieves many of the same results as signed executables and sandboxing, and some more (and vice-versa).

    Interesting links, but an awful summary.

    1. Re:SELinux != UNIX multi-user security by Anonymous Coward · · Score: 1, Interesting

      Except that the essentially randomized configurations of SELinux are so complex that no one, and i mean *no one*, uses it in production. Out of roughly 30,000 Linux systems I've helped deploy, it's been left active in "Strict" mode in about 3, and those had to turn it off pretty quickly as projects found it hampered actual work.

    2. Re:SELinux != UNIX multi-user security by Anonymous Coward · · Score: 0

      Then those projects obviously had no need for security. On systems where you do, you design the system and the SELinux rules in sync, making sure that the rules accurately describe how the system is intended to work. Switching off SELinux in those systems is never an option.

  5. Unix WIndows NT security? by dgharmon · · Score: 1

    "To discuss operating system security is to marvel at the diversity of deployed access-control models: Unix and Windows NT multiuser security .. This diversity is the result of a stunning transition from the narrow 1990s Unix and NT status quo to security localization"

    To mention Unix and Windows NT security in the one sentence, just begs credulity ...

    "Windows NT and its successors .. were not initially designed with Internet security in mind"

    --
    AccountKiller
    1. Re:Unix WIndows NT security? by Em+Adespoton · · Score: 3, Interesting

      "To discuss operating system security is to marvel at the diversity of deployed access-control models: Unix and Windows NT multiuser security .. This diversity is the result of a stunning transition from the narrow 1990s Unix and NT status quo to security localization"

      To mention Unix and Windows NT security in the one sentence, just begs credulity ...

      "Windows NT and its successors .. were not initially designed with Internet security in mind"

      I think you're confusing Windows NT the operating system (NT3, NT4, 2000, XP, etc.) with NT the kernel and security model, which was designed to be POSIX compliant, which implies lining up with "unix multi-user security" and is also done in such a way as to be tweakable to mimic many of the SELinux advancements. The OS I could do without; the security model as originally baked in (and then ignored in preference of interoperability with DOS/9x -- but it's still there) is actually pretty network-savvy. It's not the architecture team's fault that the OS team dumped a sieve on top of their nicely designed core and taped over some of the main security features on which the architecture hinges.

      Not meant to sound like an apologist; it's just that I'm really impressed with a lot of the work that early team did. They did it well enough that you can, even now, modify the commercial OSes that Microsoft releases to run in a manner that reflects the original network-savvy security architecture, without resorting to Active Directory etc. Of course, a lot of "Made for Windows" software won't run on it in that configuration, but we've learned to expect that with every MS OS after XP anyway.

    2. Re:Unix WIndows NT security? by Anonymous Coward · · Score: 0

      Internet security and operating system security are two entirely different beasts. You need a basic security course.

    3. Re:Unix WIndows NT security? by Runaway1956 · · Score: 1

      You get a nod, for seeming to know your stuff. I think you may actually be right, in some alternate reality.

      The problem is, in this reality, only the unix-likes have ever been released with a functioning security model. The security on my computers, as installed and scripted by default, is time tested, and has been improved with time. The Windows security model mostly just sits in the backroom, next to an open door (or window) and collects fungus. Almost no one actually brings it out into the workspace, and uses it.

      Yeah, the model is there, but like an old forgotten Revell model sitting in direct sunlight, it's been bent and warped while dust settles on it.

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
  6. Packages signed in all Linux distributions by loufoque · · Score: 1

    All Linux distributions already use signed packages.
    The only difference is that the kernel doesn't enforce that all programs are signed, it's simply the application installing them that checks it.

    1. Re:Packages signed in all Linux distributions by Anonymous Coward · · Score: 0

      All Linux distributions already use signed packages.
      The only difference is that the kernel doesn't enforce that all programs are signed, it's simply the application installing them that checks it.

      Right, signing the installer is easy to do, and not all that helpful. Enforcing signatures on all programs, including configuration and data files the binary shipped with, is harder but far more valuable.

    2. Re:Packages signed in all Linux distributions by jedidiah · · Score: 1

      Not really. It's great for tyrants though.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    3. Re:Packages signed in all Linux distributions by tepples · · Score: 1
      Anonymous Coward wrote:

      Enforcing signatures on all programs, including configuration and data files the binary shipped with, is harder but far more valuable.

      Let's assume for a moment that this is true. Is it also valuable to restrict the owner of a computer from being able to add the public key of an additional signer? If so, how?

    4. Re:Packages signed in all Linux distributions by Anonymous Coward · · Score: 0

      Right, signing the installer is easy to do, and not all that helpful. Enforcing signatures on all programs, including configuration and data files the binary shipped with, is harder but far more valuable.

      It's barely more valuable.

      If your development environment (where you build your packages) is not secure, then both methods are useless as they would result in signed but compromised programs. If, on the other hand, your development environment is secure then all you need is to know that the package came from there, making signatures of the packages alone sufficient.

      If you wish to use packages that a potentially untrusted person made, e.g. install the distribution's packages straight from the server without any inspection, then your security requirements are too low to bother with a security enhanced OS in the first place.

    5. Re:Packages signed in all Linux distributions by TheRaven64 · · Score: 2

      It's not much more valuable. The line between code and data is often quite blurry. For example, a lot of browser exploits have been due to vulnerabilities in libpng or libjpeg, where a malformed image caused some part of the input image to be treated as code. Even if you signed the entire binary, all of its libraries, and all of its config files, you aren't guaranteeing that the code is bug free. It protects you against a specific kind of adversary: one trying to persuade you to install a trojan by pretending to be someone else. This is a pretty rare form of attack. Most trojans don't pretend to be someone else, they pretend to be someone useful or fun. For example, things like screensavers and little phone games, not copies of Microsoft Office or Adobe Photoshop.

      If you want to be protected against trojans, then you want to run each application with the minimum privilege that it needs. This is mostly a UI problem: you must define a set of restrictions that can confine applications at the required granularity yet still be comprehensible to a typical user. For a case study in how not to do it, see Android, which fails on both counts.

      If you want to be protected against non-malicious, but exploitable software, then you also need compartmentalisation, so that a compromise, for example, in libpng, does not give you the privilege of the entire application (for example, access to all of your documents if it's in an office suite, or access to your Internet banking if it's in a web browser). This is the focus of Robert's current research (I should add a disclaimer here that I am part of the same project), because current architectures don't scale well to the required level of compartmentalisation. If you use the Chrome (and Capsicum) model of one-process-per-sandbox, then you quickly find performance limited by the number of TLB entries. On a recent Intel chip, this is somewhere in the 128-256 entry range, and if you need one process per sandbox with at least one code and one data page mapped at a time then you very quickly find that you're spending all of your time in TLB misses (this is why Chrome weakens its sanboxing if you have more than about 20 tabs open). Fixing this requires some architectural changes: it's not enough to just add TLB entries (aliasing effects hurt you), and even if you could they are constantly-powered TCAMs and so power efficiency means that you want the TLB to be as small as possible.

      --
      I am TheRaven on Soylent News
    6. Re:Packages signed in all Linux distributions by Anonymous Coward · · Score: 0

      What are you smoking?

      It depends on who's in control of verifying the signatures and how. Please try not to oversimplify so much that your quip is more than useless.

    7. Re:Packages signed in all Linux distributions by Anonymous Coward · · Score: 0

      Why would that be the case? Why are these responses so hostile? Why are you making such a contrived example that obviously biases away from any form of private security?

      It's my damned computer. I, myself, make the security choices. Obviously.

    8. Re:Packages signed in all Linux distributions by tepples · · Score: 1

      DARPA Open Source Security Helped FreeBSD, Junos, Mac OS X, iOS

      Enforcing signatures on all programs [...] is [...] far more valuable [than on the installer alone].

      Is it also valuable to restrict the owner of a computer from being able to add the public key of an additional signer?

      Why are you making such a contrived example that obviously biases away from any form of private security?

      Because Apple and the major video game console makers are known to base their business model on "restrict[ing] the owner of a computer from being able to add the public key of an additional signer".

      It's my damned computer. I, myself, make the security choices.

      Not if your computer is an iPod touch, iPhone, or iPad, as per the headline's mention of iOS. Owners of those devices are required to put their faith in Apple.

  7. Re:NASA/DARPA and making the world better - openne by Anonymous Coward · · Score: 0

    NSA, not NASA. Though they are both fond of satellites.

  8. Re:NASA/DARPA and making the world better - openne by unixisc · · Score: 1

    Actually, following DARPA's decision to yank support of the POSSE project allegedly due to comments of Theo de Raadt, it had been theorized that DARPA subsequently took a dim view of not just OBSD but other BSD projects, not related to Theo, such as FBSD. So given that, the headline of this story is somewhat surprising.

    It however does explain why DARPA developed SELinux, as well as making their security features more based on Linux than the BSDs