Slashdot Mirror


$1.2M DARPA Contract for FreeBSD Security

NAI Labs has been awarded a $1.2 million contract for FreeBSD security development. The main focus for this contract is to develop the TrustedBSD security extentions. The name of the project is CBOSS, (Community Based Open Source Initiative), led by Robert Watson and Lee Badger, and such developers as Kirk McKusick, Poul-Henning Kamp, Jonathan Lemon, and Eivind Eklund will work on it as subcontractors. I am excited over the news; the press release can be found at NAI Labs' CBOSS website.

7 of 90 comments (clear)

  1. Re: OpenBSD by Anonymous Coward · · Score: 4

    OK people who think it should be OpenBSD and not FreeBSD, you have to understand some basic concepts before you even talk.

    FreeBSD approaches security /much/ differently then OpenBSD,

    OpenBSD audits their code and tries to remove every single bug before they release, they also improve cryptography preformance and support alot of ccrypto accelerated hardware, as well as basing much of their security on strong cryptography

    FreeBSD, on the other hand looks for bugs and tried to eliminate them of course, but it is not it's main focus, and it is not its appraoch to security. What they do is have alot of security /features/. For example FreeBSD has kernel secure levels (-1, 0, 1 etc) that you can set to decide how secure you would like your kernel to operate, for example on higher security levels you can not open up /dev/mem or /dev/kmem for writing and other things, while on lower security levels you can do pretty much what a regulat OpenBSD or NetBSD can do by default.

    Second off, Robert Watson (the guy who started TrustedBSD) is a core FreeBSD developer, and his chief job as a FreeBSD developer is security. OpenBSD has their ideas that they put into their OS, and this was just one of FreeBSD's idea's, he decided it would be nice to give FreeBSD Trusted OS extentions so he started developing it, he said many times on the TrustedBSD website that he was a FreeBSD developer and this project was a FreeBSD project, he said he is trying to make it as portable as possible and OpenBSD might be able to adopt it if they choose, but they have showed signed that they do not want to go this route with OpenBSD

    So basicly the only reason the TrustedBSD might seem like a seperate project is because they are merging it into the FreeBSD kenrel /very slowly/ and carefully, they are adding TrustedBSD extentions, much improved SMP support (fine grained locking), and Kernel threads all at the same time, so they have to be careful and think before acting/commiting,

    TrustedBSD never had a chance at being used on OpenBSD since it was started by a FreeBSD core team member who was in charge of FreeBSD security, and because it was a FreeBSD project all along

    So FreeBSD will continue to take the security appraoch of fixing as much bugs as is practical to them, they will probably not spend years going through code looking for bugs like OpenBSD but they will add advanced security features

    OpenBSD will probably continue along the same development model they are now with security in the Base system

    As far as the port system goes you can't expect FreeBSD to secure every port, there are more than 5,500 piece of 3rd party software in the ports! if you think the program in unsecure don't install it

    thanks

    -Lional Will

  2. Re:It should be 1.2 million by mph · · Score: 4
    no one writes 12. million.

    Not even Fortran programmers?

  3. Re:hmm by 12dec0de · · Score: 4

    I wonder why they did not take OpenBSD as the starting point in the first place? After all, what good is some fance capability if you have not audited the framework to start with.

  4. Re:The future of root by sugarescent · · Score: 4

    The solution under TrustedBSD is to delegate the root responsibilities to various executables. I'm not sure what this solves if root still has access to these new executables. Any ideas on how this will be accomplished?

    The main idea is that you'll have a capability (for example) that says "this user can bind to ports numbered lower than 1024" and all executables that require such privileges will be only executable by that user (or some group, or whatever). If you make enough capabilities at a fine-grained level, then you'll be able to limit root's all-knowing, all-seeing power. Obviously this capability isn't a big one, but it's the only one I can quickly recall.

    -sugarescent

  5. Sounds good by ageitgey · · Score: 5
    All slashdot open-source bias aside, this is the perfect example of how the government can use our money to benefit as many people as possible. There is nothing wrong with selling your software, but open-source is a great way to make best use of public money since the public benefits as well as the goverment agency.

    I've got no problem with Microsoft selling to Coke or Ford or whomever, but I think the government should take advantage of and improve public property whenever possible. This is the IP equivelent of public parks that everyone can enjoy and share. Instead of using our taxes to further the causes of private companies, we can use our taxes to improve software for everyone.

    --
    Uninnovate - Only the finest in engineering.
  6. Important to Community... by powerlinekid · · Score: 4

    BSD, Linux... we may be different boats but its still the same ocean. So as a linux advocate, anytime something good happens for BSD or any other Open Source initiative its good for the community. And lets face it, this contract is huge for the community... not so much as in oh, well damn the government is going to fund FreeBSD, but as in the govt is going to fund an Open Source project. This is just another step down the road to general public acceptence... what will all of microsoft's FUD matter if Open Source (Linux and BSD) have the Fed, media and hundreds of thousands of brilliant programmers behind it?

    --

    can't sleep slashdot will eat me
  7. The future of root by LinuxDeckard · · Score: 5

    In the introduction white paper section II.b (Fine-grained System Capabilities), they describe the root account as being a significat source of risk (if you're rooted, you're owned). The solution under TrustedBSD is to delegate the root responsibilities to various executables. I'm not sure what this solves if root still has access to these new executables. Any ideas on how this will be accomplished?

    --

    UNIX *is* user-friendly. Its just more selective on who its friends are. --Scott Adams