Slashdot Mirror
DARPA Open Source Security Helped FreeBSD, Junos, Mac OS X, iOS
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."
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
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.
"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.
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.
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