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.

15 of 90 comments (clear)

  1. Re:Government contracted open source? by Anonymous Coward · · Score: 3

    Actually, it seems more likely the government is getting a great deal: by making the results open source, they'll get great technology transfer, and the developers do this stuff as volunteers anyway, so they're dedicated to doing it right, and will work outside their normal work day if they need to. It's hard to imagine a better pool of workers :-).

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

  3. Re:Sounds good by jandrese · · Score: 3

    Arrr! I've been trolled!

    Anyway, if you have some Public Domain OS in mind, I'd love to hear about it. The BSD license is just about as close to Public Domain as you can get, with the only major restriction being that you can't simply grab the code and claim you wrote it (under the assumption that the other party has never heard of the code before).

    So you have to give credit to the people who wrote the code (and not even in your advertising, just in the code itself). What more do you want?

    Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.

    --

    I read the internet for the articles.
  4. Re:The future of root by ocie · · Score: 3

    My question is how is this really different from sudo? I have always thought that the root account (if only used by a very select few) was a good idea. Which security system do you trust more, the one with fewer more restrictive rules, or the one with more rules. It seems to me that as the number of rules increases, the possibility of someone being allowed to do something they shouldn't increases. See Dr. Strangelove.

    --
    JET Program: see Japan, meet intere
  5. Re:It should be 1.2 million by mph · · Score: 4
    no one writes 12. million.

    Not even Fortran programmers?

  6. Re:The future of root by sethg · · Score: 3
    1. Even if root has access to all of the finer-grained capabilities, the access doesn't work in the other direction. For example, imagine a mail daemon with the capabilities to (a) listen on port 25; (b) write to any subdirectory of /var/spool/mail. In traditional Un*x, that daemon has to run as root, and therefore subverting that daemon lets you do anything root can do. In a system with finer-grained control, subverting the mail daemon might allow an attacker to wipe /var/spool/mail and broadcast spam through port 25, but the rest of the system remains safe, because there's no way for the process formerly serving as the mailer daemon to acquire full root privileges.
    2. I've heard of a trusted Unix variant where the only way to log in as the "security administrator", that system's moral equivalent of root, was to boot the machine in single-user mode. I don't know if TrustedBSD can be configured to work the same way, but if you have a system set up like this, it obviously makes attacks over the network a bit more complicated.

    --
    --
    send all spam to theotherwhitemeat@ropine.com
  7. 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.

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

  9. Re:The future of root by J.Random+Hacker · · Score: 3

    Even with sudo, if (by some means, a root kit, say) someone obtains a root shell, the system is at that moment totally vulnerable.

    The idea behind the partitioning setup is that each exploit only grants access to a *part* of the system -- specifically the parts that the particular rootlet has access to. Using chroot for servers even partitions the file system limiting visibility to data.

    IMHO the idea is a good one. It doesn't even make systems more difficult to setup/administer, if well done.

  10. Re:Sounds good by ichimunki · · Score: 3

    I think the government should be able to use GPL (especially if there is a GPL piece of software they would like to work with). The original post brought up the point about the government using public money to develop a public resource and likened this to the public parks-- where public money goes to make sure the public has a place to go and do recreational stuff. The only way a corporation can prevent the public from using the park is to buy the park

    The problem with a BSD-ish license is that it allows a private corporation to take advantage of a public resource without any compensation to the public. The libertarians (especially those tools that think corporations deserve the same rights as people) will argue that the corporation has theoretically paid taxes and therefore has as much right to the public resource as it needs. But when/if a corporation takes that public good and uses it to further their private development (and does not pass along the public resource in the same form they received it), then they have been given a freebie at the expense of society.

    If we are going to give away public resources, we should be aware of it. And personally I'm against it. The GPL makes certain that a public resource remains a public resource, to which all users have the same right of access.

    --
    I do not have a signature
  11. 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.
  12. 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
  13. BSD developers by kraf · · Score: 3

    We've seen quite a few of them listed in the blurb, but my favorite one is still Matt Dillon.
    What a multi-talented guy.

  14. 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
  15. Re:hmm by dghcasp · · Score: 3
    Perhaps because:

    OpenBSD positions itself as a "Canadian" operating system to get around U.S. gov't regulations and the U.S. gov't doesn't like giving anything to Canada (except acid rain and fugitive criminals.)

    They offered but Theo had one of his Turette-esque attacks during the negotiations and things went downhill from there.

    Easier to convince Kirk to license the BSD daemon for the new $1 bill.