DARPA to Fund Open Source Security Research

divert writes "Just got an email on the SEC-PROG mailing list that DARPA is looking to fund security research for open source operating systems." Maybe someone should just tell them about OpenBSD, save some time and money.

Comments

If they could do this one...

[Sabalon]

2) System configuration and administration tools and methods

That'd help.

Sounds like they have some pretty high goals that require a lot of cooperation between various groups. I wonder how they intend to solicit that cooperation.

Re:Of course they aren't going to use BSD...

[JoeBuck]

Who do you think put up the money to develop BSD in the first place? DARPA, of course.

Re:Then let Open BSD people sumit a proposal.

[xyzzy]

I wouldn't say that's the way they "usually" work. If you are a university or a non-profit, maybe. If not, you work under contract to them. If you are a small business or individual, you can get an SBIR contract.

It's a lot easier if you affiliate yourself with a business or academic institution that already does business w/DARPA.

OpenBSD is not the be all and end all...

[listen]

OpenBSD is still based on the fallacy that affects unix and all clones. That you trust every program you run as much as you trust yourself. Ie security is done at a per account granularity.
Any program you run can do anything to every file you have write access to, and can also leak information by default to anyone on the internet. Not good. This means a very large trusted code base, which is a bad thing. The set of code which need to be trusted (ie the kernel and very few programs) should be as small as possible.

There are some approaches to improving security. Capabilty models look like the best hope for the future. This comment is too small to hold a reasonable explanation - take a look at http://www.eros-os.org .

Don't get me wrong, OpenBSD is a good firewall and general unix server platform, but its security model is limited by posix compliance.

Re:OpenBSD is not the be all and end all...

[rgmoore]

The set of code which need to be trusted (ie the kernel and very few programs) should be as small as possible.

There are some approaches to improving security. Capabilty models look like the best hope for the future.

I'm not sure that I'd agree that capabilities are necessarily the best hope for the future. At the very least they have to overcome the obstacle that they require a substantial reorientation of people's views toward the way that operating systems behave. I'm not saying that we don't ultimately need to do so, just that it's a substantial obstacle.

The real problem with the Unix model is that it utterly fails to implement any real least priviledge system. Every program that needs any priviledges not available to an ordinary user gets full root priviledge, so that a single security crack in any SUID root program opens up the whole system. That's worse than just account level granularity. There's literally only two levels of operation, peon and god. It's a terrible security model, and only an outrageous level of code auditing has any hope of preserving anything like real world data security. That people have been willing to go as far as they have in auditing the code is commendable (and, of course, any system can benefit from the level of auditing that OBSD has instituted) but it's not a reliable route to high grade security.

unix badness

[listen]

Unfortunately, whilst unix does kick ass in many respects, there are a few deficiencies when it comes to security. Here are a few that come to mind:

1) All programs you run are trusted with all files you have access to.

2) All programs are also given a default set of actions they can perform, eg open random connections to the internet. This is nice for leaking information. This can be amelorated via so called posix capabilities. These are more properly called privelege bits as in VMS.

3) Global filesystem. Everyone can see the filesystem. /tmp can leak a lot of information.
Chroot may help. Plan 9 style namespaces are better too. Better would be to take the human namespace out of the kernel and only give it to programs that need it.

probably lots of other things. Basically unix was designed when everything you ran on your computer was written by yourself of someone you knew and trusted. And then commercial unix just got featuritis. It would probably not be good to declare it the one true operating system.

Re:unix badness

[cheshire_cqx]

This is not the point. You basically have two permissions on Unix systems--users and root. In order to get certain things done, programs often need root privileges, which means they can do *anything*. It also means you can't have an 'audit' user who can monitor the system reliably. A bad admin who is root can cover her tracks because root can do anything. (I don't think a tripwire-type solution will work here.)

All the files for one user are the same permission-wise. That means you can't jail certain progs to protect things. Groups don't help too much with this, and don't scale well.

Bottom line--Unix has some great applications, especially with its network services. But it was *never* designed as a secure OS. Basically, some guys in a lab and some guys at universities built an OS to do things they wanted to do, working with other guys they trusted. Later some rudimentary security got added in, but this was not a basic element.

Maybe, in fact, this is *why* Unix was/is popular--OS's with massive security models tend to suck to use because all that security has a usability tradeoff. Basically, you could get stuff done on Unix, and from time to time you'd figure out how to keep people from messing with the stuff you were working on after something bad happened.

---
In a hundred-mile march,

Why DARPA is doing this

[Infonaut]

I used to work as a technical consultant at DARPA. No, I'm not trying to say I was some kind of wizard, I was a lowly Technical Analyst assigned to a project in the ISO (Information Systems Office).

DARPA is interested not in current technology, or even next-generation technology. Their mandate is to fund and evaluate what they call "high-risk, high-payoff" projects. They fully expect that most of their projects will fail to achieve their goals. However, they also realize that even those projects that fail will stimulate advances in other, sometimes unforseen areas. Of course, those projects that succeed become the wonder-technologies of tomorrow.

Another thing to keep in mind is that DARPA is a government agency, and as such has a mandate to diseminate their findings as far as possible within the federal government. I actually worked on a liason project with FEMA, where we were trying to help kick-start FEMA's web-based emergency-mitigation effort.

The secondary effect of this mandate to spread the wealth is that it's key for an agency's survival that they be known as the originators of the wealth. That is, when DARPA comes up with something, they sure as hell make sure that every other agency knows it came from DARPA. That way when the budget axe comes along, DARPA isn't first on the chopping block.

So DARPA's desire to fund this project probably has a lot more to do with going beyond what's already been done, and taking the credit for it, than it has to do with acknowledging what's already out there.

OpenBSD is not a Trusted System

[Carnage4Life]

Maybe someone should just tell them about OpenBSD, save some time and money.

The DARPA program is called Composable High Assurance Trusted Systems (CHATS) which implies that they are interested in Trusted Systems not systems that claim to be secure because a bunch of hackers allegedly have fixed all the buffer overflows. Being "secure" and being a trusted system are completely different things.

Maybe micheal meant to mention TrustedBSD which is attempting to become certified as a Trusted System?

OpenBSD not ideal

[LaNMaN2000]

The problem with OpenBSD is that it takes years to verify the security of new software releases and integrate them into the distro. Consequently, many of the included packages are old versions that have since been replaced. If DARPA could come up with a methodology that accelerated the pace of verification, they would be very useful to OpenBSD and other OS projects.

*BSD isn't research

[q000921]

Incrementally improving an existing system that, one way or another is perhaps more secure than the rest of the open source systems, isn't "research". Research is about inventing new principles and finding better ways of doing things.

Perhaps some of this research will be done on top of one of the BSD platforms. Perhaps it will be done on Linux. Perhaps some of it will be completely platform independent. But no matter what it will be done on, there are more interesting research questions to ask about open source, secure operating systems, and heterogeneous environments than whether we can fix a few more bugs in BSD or Linux.

A chance for a GUI OS come out of this?

[Bonker]

While the various *nix's and BSD's are most likely going to be the major targets of this research, what I'd really love to see come out of this is a new Open Source OS, ala BeOS, that was built on a GUI base and had shell functionality rather than the other way 'round. Not a lot of difference, you say? Sit Granny down in front of BeOS and and a shell prompt and see which one she prefers. Gnome and GTK are a little better, but to make any real changes to the OS, you still have to drop down to shell-level controls. As a graphic artist, this is bit of a dream of mine.... *sigh*... Of course, the problems here are that DARPA is going to be a lot more concerned with things like number-cruching, DB manipulation, and cryptography rather than pixel-pushing or artistic representation. There's also the fact that vast majority of developers who are even moderately going to be interested in this project are going to be *nix hackers. Artistic skill and coding skill are often found in hackers, but for some reason, you seldom see them combined.

There's still room for research

[ChrisCampbell1]

Maybe someone should just tell them about OpenBSD, save some time and money.

Maybe someone shuld just tell Michael about EROS, a GPL'd x86 capabilities OS currently under development.

Read more on capabilities and why they're important to OS security. A capabilities system is relatively resistant to a lot of the big security issues that plague other types of systems. For example, even if buffer overruns do occur, the damage that can be done is very limited. This is a really cool project.

Re:Go away darpa

[Billygoat Gruff]

Darpa should keep it's nose out of the internet business. The internet is a creation of the free market and they are trying to coopt it for the gumint.

Too bad that DARPA INVENTED the Internet! Back when they were still ARPA (Advanced Research Projects Agency). Now they've become DARPA by throwing a Defense in front of the ARPA.

So as Mr. T would say, "Cut that jibba-jabba, fool! Internet wuzn't no creation of the free-market!"

Don't beat up the good guys - and deadline's soon

[dwheeler]

Don't beat up the good guys. DARPA funded all of the early Internet work and a good chuck of BSD work as well. So, indirectly, DARPA has already provided funding to OpenBSD. And it's nonsense that the U.S. government is actively opposed to open source - for example, NSA just released a Security Enhanced version of Linux.

DARPA is trying to advance what's already available - and advances in security would be great. I suspect they will be able to make advances, since they're planning to spend $10 million on the winning proposals. As has been noted, OpenBSD is not a perfect solution - its packages are often quite old and it has many functionality limits (e.g., no support for SMP). It also doesn't meet the principle of "least privilege" - root is still all-powerful, programs can do anything their owners can, etc.

The deadline is soon for those interested in submitting a proposal. The full proposal (all copies) must be submitted in time to reach DARPA by 4:00 PM (U.S. Eastern Time) Monday, March 5, 2001, in order to be considered; it CANNOT be sent by email or fax (they REQUIRE PHYSICAL COPIES).

People interested in submitting a proposal should also read the Proposer Information Pamphlet (PIP), which isn't easy to find unless you know where it is.