Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Announcements Operating Systems BSD

TrustedBSD Announced 100

Posted by Nik from the nice-logo dept.
Kaufmann writes "It seems the BSD family has a new member: TrustedBSD. From its site: 'TrustedBSD provides a set of trusted operating system extensions to the FreeBSD operating system, targeting the Orange Book B1 evaluation criteria. This project is still under development, and much of the code is destined to make its way back into the base FreeBSD operating system; however, this site will provide access to documentation, code relating to features that are still under development, and code that has its fingers in too many places to justify integrating into the base OS.' Sweet!"
This discussion has been archived. No new comments can be posted.

TrustedBSD Announced More

TrustedBSD Announced

Comments Filter:

  • Re:Xenix lives! (Score:1)

    by Anonymous Coward
    Apparently TIS, the same company that did Trusted Xenix, also did something called "TMach" which was targetted at B3 (never got it, I guess?) The documentation (huge) is on ftp.tislabs.com.

  • Re:BSD vs. WWF (Score:1)

    by Anonymous Coward
    OpenBSD could satisfy at most a C-level evaluation, as it does not have mandatory access control, nor does it have fine-grained auditing. Currently, neither can FreeBSD; apparently the TrustedBSD extensions are intended to satisfy that lack. In order for OpenBSD to satisfy the evaluation criteria, it would have to find similar extensions, or use these extensions. OpenBSD might be able to satisfy C2 at this point.

    FreeBSD also ships with IPsec, SSH, and OpenSSL. For patent reasons (not export reasons), RSA is not installed unless the user specifically asks that it be installed (and confirms they are out of the US, or agree to the RSAref license). In the long term, all of the BSDs will be using the KAME stack; OpenBSD is currently migrating towards it.

    FreeBSD does not currently include an IKE daemon, such as the KAME racoon or OpenBSD isakmpd.

    It's not clear you know what you're talking about. Please try again.

  • Re:Revolution =! Prostitution (Score:1)

    by Anonymous Coward
    You suck and you know it.

  • OpenBSD = great BUT (Score:1)

    by Anonymous Coward
    OpenBSD is great, and functionally, the developers probably would have an easier time deriving from OpenBSD, but guys, we need to remember something very key to free software: it's Free. If these guys want to take on the challenge of moving the latest FreeBSD into a more secure codebase, more power to them.

  • Xenix lives! (Score:1)

    by Anonymous Coward
    Trusted Xenix consistently got a higher rating than any other OS except for the Wang XTS STOP thing.....

    Interesting, no?
  • You really can't implement ACLs using the
    traditional Unix security model. Fortunately,
    ACL support seems to be much more common in
    Unixes now, and with any luck all the free
    Unixes will have support for them soon. It's
    a useful enough feature that I concievably could
    change the operating system on my systems to
    whoever gets there first (well... unless it's
    FreeBSD, as I have diverse hardware)
  • The idea of ACLs is that root need not be involved to assign arbitrary groups.

    While ACLs could be implemented using generic UNIX-style groups, it would be painful at best.

    For example, under Digital UNIX (I think solaris has similar syntax supplied by setfacl), to set an acl so joe, mary, and all members of the project1 and project2 groups can access file foobie read/write, all I would need to do is:

    setacl -u user:joe:rw- foobie
    setacl -u user:mary:rw- foobie
    setacl -u group:project1:rw- foobie
    setacl -u group:project2:rw- foobie

    Now, clearly, this can be done using standard UNIX groups - but given the essentially limitless potential combinations - this is NOT a good plan.

    -Jeff
  • Ah, come on, give me at least a little credit, here. Firstly, saying that something sucks isn't always a bad thing - some people might take that as constructive criticism - I did, at least, point out WHY I thought it sucked.

    As for reading the site, yeah, I read the entire thing, and, like I said, it's mostly links that point to each other.

    In pointing out that the web site is immature, I was more taking a stab at /. for posting this article. POSIX ACL deals are available for most OS'es, even tho POSIX acls do not exist as a standard (it was withdrawn for rampant suckage quite some time ago.)

    So there. :P

    --
    blue
  • This kinda attitude seems prevalent across among the posts to this article and I find it somewhat annoying.

    Shrug, then write something on the web page explaining that. Especially given today's atmosphere wrt BSDs, it's prolly a nice idea to spell out on which side of what fence you stand ahead of time. If it's open code and you welcome all comers and would like to see it pointed to all OSs, say so. If you're using FBSD for some technical superiority, say that.

    If ya don't tell us who you are, what you do, and why, then ya can't complain when we make shit up at random. :P

    --
    blue
  • BSD-license is just as much about allowing other people to share your code as the firs ammendment is about suplying your rights to free speach. The first ammendment does not say: you can say anything you want except speaking against the free speach, no it gives you the rights to say anything you want. Free code is imo not code that others are free to use for anything but proprietary programs, but code you can do anything with.

    The way I see it the GNU-license is about making the free programs as good as possible, but the BSD-type is about making the programs, free and proprietarry, as good as possible.

    just my opinions.
  • That "Agent Beastie" logo kicks tail!

    If this thing were to ever become a full-blown BSD distribution, think of all the fun possibilities for the CD cover art. If you thought the OpenBSD one was good, wait till they show big bad crackers who think they're "The One" };-)
  • I mean, can't you just open top secret file, read it, close it, open confidental file for reading, and write in it what you have red and remembered ?

    If you can (and I cannot see any way to stop it, barring mind control), then there is no real security in it, just making a little bit more annoying to do "unsecure" stuff. And if your point is to annoy users to gain some pseudo-security, there are even better ways to do it (ask any BOFH :-)
  • For those who might be interested, this is a listing of systems certified under the evaluation criteria, by order of rating

    There is no such thing as getting (A|B|C)(1|2|3) certification. Products are evaluated to the certain criteria, but certification implies there is some certification body.
  • If the patches are contributed to the GPL'd project without having their copyright assigned to the principal author, then the main author can release under another license, but can't incorporate the code from the other authors, since he doesn't have the copyright for the combined work.
  • This post is brought to you by the letters T, h, e, and o.
    -russ
  • Yes, I know, I was countering your FUD with my own. Incidentally, go back and read my post. Did I say anything about license changes being retroactive? Did you even read my post before hitting reply?

    My point was that while it's true that the BSD developers could close their source, it's equally true that the FSF could close its source. Because the FSF alone holds the copyrights, a great deal of GPL'ed software is in just as much jeopardy of being closed as FreeBSD. The copyrights essentially negate the differences in the licenses because neither offers any protection.

    However, in neither case would software available now be affected, as you so thoughtfully (that is, needlessly) pointed out. The issue is moot, though, because neither will ever happen. The BSD developers have more than proven their allegiance to the ideals of Open Source, as has the FSF. If anything, I credit BSD teams for resisting a temptation that doesn't exist for so many Linux developers.

    © 2000 James Lanfear. All rights reserved.

  • Let's see. If I remember correctly, the FSF has the copyrights on a great deal of GNU software. Copyright owners can change liscensing as they please. Therefore, it's quite possible that the FSF will offer binary only versions of their software and will hide away changes.

    © 2000 James Lanfear. All rights reserved.

  • Amen! That guy has done a good job with leading development of OpenBSD but he needs to go to charm school.
    And who says they won't grab the OpenBSD source and give it a looksee? After all this *IS* Open Source, right?
  • And if certain UNIX vendors use (say, one whose name ends in P) valuable partnerships to try to strong-arm you into using a B1 certified system when you don't need one, run away. No amount of money is worth it.
  • If the process is "cleared" for the level of file A (call it high), it by definition may not write to a file of lower level, including B (which is at level "low"). It does not particularly address the fact that you can memorize the data and type it in again on a seperate terminal, though there are some guidelines for export to external systems (ie, printers should mark the sensitivity of all data being printed).

    In a more formal sense, mandatory access control is implemented by assigning every object (file, socket, device, fifo) a sensitivity label, and every subject(process/user) a clearence label. A subject with clearence label X may only write to an object with a sensitivity level of X or higher, and may only read from objects with a sensitivity level of X or lower. Thus, any data flow path within the system is restricted to only flowing from less sensitive to more sensitive. There a few twists (sensitivity labels are only partially ordered -- there may be levels which are incomprable, and no access paths exist between them).
  • One thing it does is that if a user at a low sensitivity level manages to insert a trojan into a higher sensitivity level users path (for instance, any way of getting it to execute is fine), that program cannot send the data back down to someone at a lower level. MAC based integrity does a better job of this, in which a process operating with a given integrity requirement acts as if all entities of lower integrity didn't exist.

    As a requirement for security, physical access control is also necessary, so for instance, a highly sensitive level might have only a single terminal associated with it, which was physically secure, so that it was possible to verify that you did not take any written data out. You can still memorize it, but the scope of possible causes for information leaks is greatly diminished. Hell, just preventing a buggy program from crashing and putting sensitive data in /tmp is a good start.

    Finally all of these trusted systems also implement extensive auditing capabilites, so in the event of a security comprimize, accesses to any particular object can be traced and examined.

    When you get right down to it, DAC is really designed from the perspective of preventing people from writing data they shouldn't. MAC primarily focuses on preventing people from reading data they shouldn't.
  • Actually, though, most of this is already handled. Not just files, but all object (descriptors) have labels. Since an X client must have r/w access to the socket to the X server, it cannot change its sensitivity level. Also, unless you are on a terminal device specified as multilevel, the shell cannot change its sensitivity label.

    As long as you stay on one machine, the actual implementation of MAC isn't too difficult, the hard part is all the integration work to assign labels and privs to everything, and ending up with a working system. However unless you inadvertantly give a program privs. it shouldn't have, none of that has particular system securtity implications, it is all more along the lines of "if you didn't do it right, it will fail".
  • You know, I have been a reader of /. for some time. I find that those who really READ the information availible here usually don't post worthless drivle about being first. Does it really matter? Does it boost your ego that much. I pitty you. I hope that you get a life soon, before you are left behind in the evolution of this world. What a waste that decrepid minds like yours can type but have nothing of importance to say.

    Now, as to the article...
    It will be nice if this project sticks with us for a while. I remember when the documentation for the os's were multi-chaptered books that usually weighed as much as the system the os was being installed on. Remember DOS 3? Almost every command had a page (if not more) dedicated to its use.

    Some of those extentions will most likely make it to my toy system. It will be good times for all. :)
  • I should also point out for the record that FreeBSD is undergoing a similar code audit to the OpenBSD effort of a few years back, and is in the process of merging most of the OpenBSD code security fixes (it's been stalled for a little while due to release engineering efforts for FreeBSD 4.0, but I expect it to pick up steam again now that the developers can refocus their sights).

    (sarcasm on)If Microsoft has taught us anything, it's the importance of getting a product out ASAP, rather than fixing any of those naughty security bugs and holes which can be fixed in v n.1 and n.2. (sarcasm off)
    ---
  • You also have to have the concept of each user being placed at a "Sensitivity" level. What the NSA director writes may be TOP Secret. What their Secretary writes may be "Confidential", that joe public visitor writes would be "Unclassified". These are hierarchical levels. Someone at 'Top Secret' can automatically read anything at a lower level that is permitted by discretionary access (ACL's and unix mode bits, for example). The person logged in at 'Top Secret' can't write material, by default, at any level below their level. Persons at lower
    levels cannot read anything above their level even if it's mode bits were set 0777.

    Say we have los alamos lab doing "Secret" government work. All the scientists using the computer there would do all of their work at the 'secret' level. This way, 'secret chinese operative' can't leak the information to a
    lower level. Even printouts are to be labeled, so theoretically they couldn't walk out of the secret facility w/a secret document (in practice physical security may be harder to enforce). Things like the camera in your watch might escape detection.

    I'm not sure how you would implement such a scheme in any straightforward way using ACLS and CAP lists.

  • IRIX 6.5 is currently in evaluation for B1
    as well.

  • Years ago, I worked with something called Trusted Xenix.
    This was put out by a company called Trusted Information Systems.

    Does anyone know if they have anything to do with this?
  • Actual certification of an OS costs vast amounts of money (millions) but that doesn't mean you can't make a product TARGETTED at those criteria - which would be almost as useful (e.g. filesystem ACLs have uses for ordinary users, not just government agencies)
  • The previous posting was written by me. (Damn slashdot, now I'm not going to whore any K4rM4)
  • You know, I don't want to sound like I'm knocking OpenBSD - I'm not - but it kind of irks me to see this particular myth perpetuated. The OpenBSD code audit wasn't really "line by line" and they didn't rebuild the OS "from the ground up". What they did was analyse the source code for lots of different types of mistake - if it was line by line, then they presumably wouldn't still be fixing bugs (when the FreeBSD auditing project started up we found quite a few minor bugs, as well as one or two more serious ones, which OpenBSD had missed so far).
  • Ignoring the insult to Nik, who has done a lot more for the free software community than you probably realise, I'll assume you were serious in your question.

    @freebsd.org email addresses are only available to FreeBSD committers - you generally have to prove yourself by doing something really worthwhile (e.g. submitting lots of ports, writing documentation, writing or maintaining nifty code, etc) before you're offered committer status.
  • Yes, it's possible, but a) then they wouldn't be releasing BSD-licensed code, but proprietary code, and b) I can assure you they're not going to be doing that :-)
  • Lets do the news 1st.

    Looks like FreeBSD is going to branch out!
    FreeBSD-i18n Dedicated to internationalizing FreeBSD (hopefully the disable will be better addressed in this release...code for the blind, the deaf, etc.)
    FreeBSD-PPC Dedicated to making FreeBSD run on PPC platforms.
    The web pages don't show it yet...but go for instructions [freebsd.org] on how to get on a list.

    >This kinda attitude seems prevalent across among the posts to this article and I find it somewhat annoying.

    Hate to break this to ya, but the big reason there WAS a split in OpenBSD's case is it *WAS* personality.

    There was a big thread about this on daily.daemonnews.org, but it got deleted by the people who run the site.

    The thread went into acusations involving the FBI, malicious code deletion, etc la.

    It all reminds me of what the head of EE told me in college. Most technical staffers are never fired/let go because of their lack of technical skills, but because of personality/personal issues. This thread has the 'annoying' comments about personal loyalities because there is much truth to them.

  • No, you don't understand what you're talking about. Both UNIX and NT are C1 systems.

    If what you mean is, "both UNIX and NT possess the features needed to get a C1 rating," you're right. What you said is wrong, though. UNIX can't get a C1 because there isn't any single "UNIX". NT 3.51 with no networking was granted a C-something rating. This has nothing to do with reality, but doesn't prevent marketing using the rating.

    There is a lot of extra overhead to do MAC checks and MAC intentionally sort of puts people in a prison.

    It is true there is additional work necessary to check additional policies. Traditional DOD-style MAC checks are fast -- one comparison and a few ands and equality checks. This doesn't have to be significant. As for "putting people in a prison," you're actually more interested in putting Trojan Horse programs in prison--and if you don't need the feature, just give everything the same sensitivity label.

  • The only question I have is why they wanted to base this on FreeBSD instead of OpenBSD. Last I checked FreeBSD and NetBSD both had "sub-optimal" code that had been fixed during the OpenBSD audit.

    Interesting choice.
  • And we should be proud that you're a heterosexual low brow pizza boy; what's your point?

    In case you couldn't take the hint from my last post, I'm as gay as Nik. I may be low brow, but I'm no pizza boy. I've been called many things in my time: slut, tramp, two-timing hussy, but NEVER "pizza boy".

    I'm afraid I'm going to have to demand satisfaction. En guarde!

    "What's my point?" Wouldn't you like to know, missy... drop by Francis' next time you're in New York and you can see my point as much as you want.

    Bitch.

  • By the way, Kris: what does it take to get one of those l337 "@freebsd.org" email addresses? Do all of the developers get them, or just the core members?

    I'd be willing to help you guys out, if I could get an @freebsd.org email address, so I can be as cool as you and Gay Nik.

  • Thank you for the response to my question, Kris. I'd like to talk about your attitude towards Nik, though.

    Ignoring the insult to Nik...

    It wasn't an insult! Seriously, Nik is gay. And he's proud of it, as well he should be. He shouldn't be forced to hide in the closet just because you think it's "weird". You think that Nik shouldn't be allowed his human rights?

    For God's sake, it wasn't an insult. I know his ex-boyfriend. Nik knows who I am. He's not offended. You've obviously never spent time in the gay community. We queer nancies have to stick together, and brotherly ribbing is looked at ironically, rather than patronizingly.

    We should all be supporting Nik in his decision to be forthright about his homosexuality. I think he'd appreciate your support too, Kris. It's not easy. Even geeks, traditionlly shunned, are surprisingly homophobic. I find it disgusting.

    Nik, if you're reading this, I apologise for Kris.

    ...who has done a lot more for the free software community than you probably realise

    I don't need the lecture. I know Nik a lot better than you probably do, Kris.

  • Oh.

    I really feel stupid now. I thought those folks were attempting to promote open source to government agencies as an alternative to commmercial solutions...

    Now if you are talking about the main effort of this is to bring BLS to desktop systems that your average Joe runs because that would be 1337, then I rest my case here.

    Mmmm.

    Yours,
    --Albert
  • I've used OpenBSD and FreeBSD. I highly recommend both. What the heck do you think our servers are running... Windows??


    Nathaniel P. Wilkerson
    NPS Internet Solutions, LLC
    www.npsis.com [npsis.com]
  • Aside from default settings and kernel behaviour, there's becoming less of a difference between OpenBSD and FreeBSD (and in fact NetBSD as well) and I expect that trend to continue as time goes on. Everyone agrees that the often-cited "goals" of the three projects are all worthy things to pursue, the difference has just been in which order to pursue them, and so as time goes by the projects are expanding in the directions of the others.

    Does this mean the code for each *BSD will eventually merge? It's always bothered me that 4.4BSD-Lite forked in the first place.
    ---

  • It seems to me that the effort would have been better spent on OpenBSD [openbsd.org]. Does anyone know why they skipped OpenBSD?
  • You'll never see "Linux" there.

    Security ratings are assigned based on the various components of the OS, and the kernel is just one of those.

    You may see "Red Hat Trusted Linux 17.23" there, or [Free|Open|somenew]BSD, but not "Linux".

    You could see "MumbleBSD x.x" listed because they each have a single distribution. If they felt like coughing up the dough for testing, that is...

  • I do wish they had started with OBSD, tho. They prolly chose FBSD because of personal loyalties to someone(s) on the FBSD project - or because of the opposite on the OBSD project. :P

    This kinda attitude seems prevalent across among the posts to this article and I find it somewhat annoying. I have no issues to the OpenBSD project, I support what they do, but they aren't the only OS attempting to be "secure by default". FreeBSD is taking measures towards that also, by incorporating ssh and ssl libraries in the base distribution and is also working towards a code audit similar to what OpenBSD does.
  • ... the we'll get to the point where there will be so many diverse "flavors" of Linux and BSD that you will have to "port" all software you want to use so that it works with your machine.

    While there are way too many flavors of Linux floating around, this TrustedBSD may serve a good purpose. It's aiming at B1 level security, so it'll be much more secure that normal x86 unix clones. What's Linux secutiry at? c2? Never reached c1 yet I believe.

    Is there anyway to standardize it all?

    POSIX does a great job. A lot of source code just needs a minor tweak or fix to compile on other platforms, which there are a few utiliteis at aid in doing that itself... If we standardize it all, we'd be stuck in the same rut... Options are great. I do think it's silly to have a specific linux distribution for a piece of hardware, but to have choice likes this BSD is good... to have Slackware vs Almost_slackware_but_changed_the_opening_installat ion_ascii 9.42b is quite silly :)

  • I'm a little confused. While I've looked for details on how to verify that a system is B1 compliant, I only seem to find vauge references.

    I don't see the practical difference between a system that's B1 compliant and one where ACLs are added (1) [uni-bremen.de] (2) [bestbits.at] and all accounts including root are severly restricted [lids.org] -- and both of these security measures avaiable under Linux.

    I realize that verification testing is done on a per-installation basis, so many of the details will be specific to that installation. ...yet, all security is specific to the tasks and installation, so this doesn't clear up anything.

    The general goals including many specific "the system shall" type directives, should be readily available...but where?

    Tools like LIDS under Linux [lids.org] and other kernel patches to handle ACLs seem to do the job...so what's missing?

  • For those who might be interested, this is a listing of systems certified under the evaluation criteria, by order of rating. So, when do we see Linux there

    No, but that's not the fault of the OS. They never even evaluated it, nor OpenBSD, nor FreeBSD, none. They've stuck with big name crap. Here's [ncsc.mil] the list of products that have been evaluated. Interesting that NT, the OS of choice when it comes to r00ting servers, is high on the list of secure solutions. Blame the operator I guess..
  • ... the we'll get to the point where there will be so many diverse "flavors" of Linux and BSD that you will have to "port" all software you want to use so that it works with your machine.

    Is there anyway to standardize it all?

  • Why apply these changes to FreeBSD. It would seem that OpenBSD, alreading being security audited etc.. would be far the better choice.

    Are there some features of FreeBSD they wish to preserve? And why not merely attempt to integrate these into OpenBSD?
  • But history has proven differently. If your paranoia was valid, BSD wouldn't even exist today.

    Its not about money, its about progress. Open Source isn't about true open source, its about progress.

  • Re:They've bitten off a lot, here.. (Score:2)

    by Anonymous Coward
    Apparently the APIs for extended attributes and ACLs were committed to the source tree in December, so were actually part of 4.0-RELEASE. The supporting code apparently isn't there-- wonder if it can be loaded as a loadable kernel module, or if one has to apply patches?
  • As far as I know [...] Multics was the only OS ever certified at the "B" level.

    Nope. DG/UX has offered a B2 security option [dg.com] for many years now. Trusted Solaris and Trusted IRIX have both been certified at B1, along with several others. Even Trusted Xenix (!) of all things managed to get a B1 rating in the early 1990s. Personally, I wouldn't trust Xenix with anything. It ranks right up there with Interactive Unix as one of those OSes I'm glad I'll never have to use again :-)

  • You've clearly got a point there: in theory I shouldn't be able to decide to lower the security of data.

    So you eliminate any way of creating a lower security file than the highest level of security you currently are. You can read anything you're cleared to, but can't possibly create a lower security file. The system could then have two paths

    a) I can't log in at a lower security level
    so I can't under any circumstances share that information; you've removed all discretion from the process. Note that I could still walk down the hall and tell the uncleared janitor, verbally, anything I had learned.

    b) I can log back in at a lower security level
    In which case I'll just memorize what I read before and write it into a new file at lower security.

    You could argue that it's more secure since I can't do that algorithmically; I would have to literally memorize every character I wanted to commit. Certainly a gigabyte of nuclear research data would be hard to compromise that way.

    But that doesn't sound like a Secure (in the OpenBSD or BugTRAQ "strongest-possible" sense) solution at all. Just because a secret file happens to be short and in English doesn't mean it should be easier to compromise, since "short and in English" is not part of the security description of the file. I would much rather have a traditional POSIX with well-planned access groups and discretionary security, and assume that anyone I show a file to can share it at lower security. In other words, since the leak is there, I would argue you should make it a flood (so it's unmistakable) rather than claiming it doesn't exist (since it obviously always does).

    I note this is equally true of the "military-style" hardcopy document security system in the analogy in the post below. Which is probably why that's a dumb system.

    Again, just my opinion. But I don't think MAC does anything more than obfuscate a truly insecure (in the sense that every human is insecure) system.
  • That is what we have policies for. It would be against policy to copy top secret info into a secret document. If you have access to top secret info then you are trusted to handle top secret info properly.
  • You're assuming mistakenly that the checks are done somewhere in user space, such as in the shell or in cat. This is not the case. The checks are done in the kernel. Thus in the example given you would be able to open the two files but if you fread to a, the kernel will not allow you to write that info to b, but instead will return an error if the SL of the file you are trying to write to is bellow the one you have read from. Labels permeate the system, labeling files, processes, et al.
  • that is not correct. think about it: joe author releases a book and sells it for $20 under a copyright that allows people to read it in the home. then they change the license and say you need to pay them $20 each time you read it.

    they could release new versions of the code under a binary license, but not change the old copyrights. in a sense it's a contract and needs the consent of both parties.

    the fsf owns the copyrights on several projects (not linux though), and it does so in order to help fight violations. only the copyright holder can sue for copyright violations - and i'm sure joe developer isn't interested in hiring lawyers...
  • yes theoretically the several dozen authors for any given gpl project could release under another license. but they'd all have to agree. the bsd license doesn't require that.

    as for your rather nasty comments i was merely replying to a comment that the bsd license was designed to help share code. it isn't. it's designed to share software. the audience of developers that can use bsd software is theoretically larger since ones that want to release binary only software can do so. bsd proponents will surely feel this is true. obviously some developers who are keen on the gpl won't want that, but since the s/w development industry has been largely binary driven i would guess that the bsd license is more attractive.
  • RE: Something they started last Thursday.

    Aren't you glad nobody made this obversation about Open-Source in the early '90s?

    Where would the world be without forward thinking?

    For those who've been criticizing why it's just another spliter faction from {Free|Open|Net}BSD, Did you even bother to read their annoucement?

    Here's an Excerpt from the Announcement:

    The TrustedBSD extensions will be made available under a two-clause BSD-style license , which permits integration of the extensions into projects under almost any licensing model, both free and commercial.

    A web site is now online to act as a central source of information about the project, and as a distribution point for code not yet committed to the FreeBSD source repository.

    Furthermore, there is some POSIX-1E ACL support in FreeBSD 4.0-RELEASE. So your "18 months" of hard work is well underway.

    Robert Watson, from the TrustedBSD project wrote them.

    sigh.

  • WinNT advertised itself as having passed Orange Book testing (at C4, not "B"-anything, IIRC), but only for WinNT 3.51 with all patches and explicitly with no other computer connected (no network or modem even installed on the machine)

    WinNT4 never even came close. Yet MS often billed NT as 'secure' to Orange Book "C" level.

    As far as I know (and per the Multics home page when I last looked -- a few weeks ago) Multics was the only OS ever certified at the "B" level. That may be the only 'multi-user OS' however.

    I haven't used Multics since I was 16, in the late 70's, so I'm not really a partisan of it. Still I did learn my first three programming languages on it (Fortran G/WATFOR/WATFIV, APL, and LISP).
    I wouldn't go bcak (to Multics, age 16, or Fortran) for anything!

    __________

  • I'd like to apologize for my remark on Multics being the only "B" certified OS

    That claim was removed from the Multicians [multicians.org] website (possibly as the result of a /.'ing a couple of weeks ago). It stuck in my mind because of the high "You gotta be kidding!" factor.

    Indeed, I wasn't actually prepared to submit the entire article. I was running Mozilla M14 on my beta machine, and it hung while I was fact-checking. I guess I hit the wrong key sequence and the article got submitted by mistake.


    __________

  • I cut data from file A, and paste it into file B. I can then control who has access to the information in file A by allowing them access to file B (which contains all the information from file A). This would be the case for ACL's, and all unix style permissions.
    MAC control on the other hand stops this.

    Whoa. That's tight. But is that really possible? You could stop someone from doing 'cat A >> B', but what if I, say, load up a text editor, import A, and write to B? Or if anything, write a small program that does open(A); open(B); fread(A); fwrite(B);? Or just looked at A, switched to another virtual terminal, and typed the text verbatim into B?

    I see how you could make changing the security level of particular data (not just the file) inconvenient, but how can you make it impossible?
  • yes theoretically the several dozen authors for any given gpl project could release under another license.

    The typical free software project has only one copyright holder. There are very few exceptions. Simply being a contributor does not make one an owner.
  • Get off your self-righteous high horse and rethink what you just wrote!

    Not only is it possible under the BSD license, IT IS ALSO POSSIBLE UNDER THE GPL or any other license. Licenses do not grant permissions and conditions upon the author, only upon the user.

  • This is Unix. Stop acting so helpless.
    -russ
  • You can mostly implement ACL's using file ownership, permissions, and groups. Yeah, root can do too much. It would be reasonable to parcel out most of the things you have to do as root to groups. E.g. if you want to open a socket with a port 1024, the user you're running as would need to be in the "lowsocket" group.
    -russ
  • POSIX is POSIX. You only need to "port" things that are non-portable (huh?) and not supported by any standard. Things like how one changes the firewall rules are obviously going to be different for every implementation, but if all you want to do is play Quake or fiddle with the tape drive, then POSIX does the job.
  • You said "In truth, I'd be surprised if FreeBSD wanted this in the core OS. A B1 level of security can get quite annoying in situations where security is not your paramount goal. There is a lot of extra overhead to do MAC checks and MAC intentionally sort of puts people in a prison. "

    All of MAC stuff is in the core of the IRIX OS. It's just that it is only turned on when booting from specially labeled (has MAC) disk.

    It doesn't get in the way but should be in the core OS so people aren't as likely to break it.

    MAC also doesn't have to even be turned off for a Unix system to operate 'normally' -- not even that expensive. You set all Sensitivity labels on all users and objects at 0 and Integrity at 0, and have no divisions or categories. That's a 32+32+16 bit compare which is negligible compared to file access times. In that instance,
    only discretionary access would actually be checked. Of course then you *could* decide to protect system files from tampering by making root run at an Integrity level of 1 and all system files also having Integrity level 1. Then MAC would prohibit lower level processes writing anything in the "System File Group" (Trusted Computing Base or TCB) and root couldn't execute anything that wasn't in the system group (no trojans). Add file based capabilities for executables and have root having no special privs (or few), and getting root access does you no good. But if you wanted to run as 'normal',
    just have Sens=0 for everything.

  • Okay firstly, somebody moderate this up, because it makes a lot more sense than other things I've read on the subject.

    Secondly, I have a question: When the system drops your security to a less secure setting, that is only per-session, right ? So if you log out, log back in then you're top secret again, no ? Sooo, there's still the possibility of the user doing what the original poster said, i.e. opening vim in one login session, opening the file in another, and copying it. Or even print out / scan in, if the user had privileges to do both...

    Right... ?
  • I'm not sure the differences are as large as you claim. On the issue of crypto, FreeBSD 4.0 includes: IPSEC OpenSSL OpenSSH Kerberos 4 and 5 Support for link-level encryption on ethernet/wireless cards that support it etc. About the only extra "crypto" thing I could think of that openbsd has is encrypted swap, which is planned for FreeBSD too. Is there something I've missed?
  • > Does this mean the code for each *BSD will eventually merge? It's
    > always bothered me that 4.4BSD-Lite forked in the first place.

    I don't know about merging - the personality differences between certain
    of the project leaders, not to mention so much code divergence (lots of
    minor changes) may prevent that from ever becoming a reality -
    but the three projects are certainly converging. FreeBSD is being ported
    to new platforms, NetBSD and FreeBSD are both gaining new "integrated crypto"
    features and increasing the attention to security, OpenBSD and NetBSD
    are working on SMP support, etc.

    There's a fair bit of parallel effort going on, but on the other hand
    there's an awful lot of code sharing. e.g. the USB stack is shared between
    at least NetBSD and FreeBSD, with fixes and enhancements going in both
    directions, OpenBSD and NetBSD regularly port drivers from FreeBSD, etc.
  • 1. Never -- the Orange Book certifications are for people trying to sell software to the government. Given the fact that no one can close Linux to be the sole provider of there version of "Trusted Linux", and given the high cost of actually getting a system certified, it's not likely to make business sense to do this. It might make sense for a BSD, since you can make the particular version that got certified proprietary.

    2. As soon as the NSA opens up their modifications to Linux. They are actually working on it now, but most likely, they won't release it. The NSA isn't in the habit of releasing anything back to the outside world. They think *everyone* is a potential enemy. Look at the history of DES, and there's strong evidence that the NSA had differential cryptanalysis 10-15 years before the private sector.

    But it's pretty irrelvant. The "security" implied by these certifications isn't the type of security that is usually of interest to people outside the military. The only case where I can see it being needed would be with medical records or financial records, but in those cases, you also have a whole bunch of data validity and availability issues that the Orange Book doesn't address.

    --Kevin
  • >Last I checked FreeBSD and NetBSD both had "sub-optimal" code that had been fixed during the OpenBSD audit.

    *yawn*

    If this kind of comment was made about RedHat vs Mandrake vs (anyone but) LinuxOne, it would have been labeled as flamebait/troll.

    Audit issues found in OpenBSD that were appropriate to Net and FreeBSD were applied to the release. And, I'd bet some of these issues were then applied to the package they came from, in addition to Linux.

    That is the beauty of OpenSource. Unless you can prove that no patches from OpenBSD were applied to Net/FreeBSD then you are either ignorant or spreading FUD.

    Now, you seem to be expressing these 2 ideas:
    1) lets all work together so we move faster/better
    2) OpenBSD has the 'best security'

    Lets all work together...each project has different goals. And now a group want to improve FreeBSD. Good for them. If working together is #1, why 150 different Linux distros? And, what about 'many eyes make bugs shallow', does this not apply to design ideas? Many minds working in different directions provide the different lines of thinks that will find a better path.

    Best security....Charles Hannum (root@ihack.net) pointed out at a BSD dinner that OpenBSD security isn't, FreeBSD memory management isn't, and NetBSD portability isn't. OpenBSD is as secure as a sysadmin makes it, FreeBSD's VM doesn't work quite right (this statement was made months ago...), and unless you have the toaster that NetBSD runs on and WANT to turn it from a toaster to a NEtBSD Box...it is kind of pointless. Security/VM/Portability is nothing more than examples of successful marketing...taking a small difference and making the biggest possible deal about it. Is the ability to run the OS on Dreamcast worth a better VM? Or, is good security worth giving up a 2500+ ports collection? Or is it worth giving up the ability to run voice recognition software? OS choice is about choice. And when one makes a choice, one gives up something in favor of something else.
  • What is more pointless is WORRYING about moderation, and if your POV got moderated up or down.

    It seems some people take it WAY to seriously. I used to moderate my points I got down all the trolls/flames. But, given there is no reward for beating down the noise, there is no incentive.

    If a moderation change is needed, it should be to allow for some people (oh how to choose!) to have massive points to beat down the trolls. If the trolls can't be seen, they will eventually go away. Perhaps 'congratz! U have 20 trol beat'n points. Thump away!'

    Right now, as they admit...they only exist to burn moderation points.
  • Take a look at HP's Virtual Vault, which was based off a smaller company's certified B-level refitting of the HP-UX and Solaris kernels.

    The latest evolutions of HP, based off HP-UX 10.xx tree, are no longer certified, since this auditing must be done every time the source changes, but there /have/ been OS's other than Multics that achieved B-level.

    The question at hand is, will the open source movement be able to halt its endless updates and improvements to sit down and do a full audit of FreeBSD, with these extensions. Even HP is loathe to do it, and VV/HP-UX's march of progress is considerably slower in tempo.

    Pooh-pooh'ing aside, I am very eagerly awaiting a BSD with finely grained privileges, and I wish the implementors the best of luck!
  • I'm currently on 4 moderator points, and so I'm browsing at -1 and reading the articles carefully, and trying to moderate in areas where I'm not biased (not that I can, I prefer to post in those forums).

    Browsing at -1 is a real pain. I'm looking for abuses of moderation, but all I see are hundreds of trolls, flamebaits and idiots posting gibberish. What is it about Slashdot that has attracted these people here? Do they really have nothing better to do?

    I really want to moderate positively, I'd love to find a load of articles that are really worth my ticking them as interesting, insightful or funny. But what are the chances that I'm going to come across one of those before I come across five posts that are so full of swearwords (and no content) that I do the slashdot community a greater service by sending them below the surface? Every so often I come across a good post, and it's with a sense of achievement that I can actually moderate it up, but the sheer volume of junk that I have to wade through in order to find the gems means that I tend to run out of points before I get there.

    Not moderating down the trolls is not an option. When I'm not moderating I browse at 0 because ACs sometimes post interesting articles, and at that time I tend to thank the moderators that got rid of the trolls for me, so I do the same. The solution isn't about content, nor is this constant moaning about the quality of moderation going to get Slashdot anywhere - you have no real data on who moderated what, and how much they knew about it, and what proportion of moderators do a good or a bad job. The problem is accountability for posts, and this whole veil of anonymity thing is not helping in many cases (please note that I implicitly acknowledge that in other cases it is essential).

    All this bitching at moderators is really pissing me off - it demotivates me from making an effort, since there will always be a hundred posters out there to criticise moderators no matter how much time and effort I personally put into it.

    A big problem with slashdot is that regardless of the subject topic, people prefer to discuss the value of slashdot, the quality of moderation and the lack of quality articles. This problem is about users, not management.

  • Sorry about not closing the /B tag.
  • I am not sure about you guys, but I begin to notice a pattern developing here. So every now and then, you would see somebody coming up with a not-so-new-idea. The content of that is not important, as long as it runs on linux/bsd, and most importantly it is open sourced.

    Yes. The source is free, but the NSA evaluation process IS NOT!

    I remain skeptical about this one (and other opensourced BLS projects we came across previously). I mean, where are they going to get the fundings and needed financial support? NSA is, obviously, not going to entertain a bunch of coders with "opensource" bandanas wrapped around their foreheads; On the other hand, if the OS has not formally passed the BLS evaluation (which is going to cost an arm and a leg), they couldn't even use the term BLS (B Level Security) OS.

    I remember when Hewlett Packard rolled out its BLS HP-UX 10.24 a couple of years ago (based on earlier version of HP-UX BLS 8.04/9.09, they were B1 at that point I believe), the marketing folks claimed that 10.24 achieved the B2 evaluation standards with MAC/DAC enforcement on system, network level as well as secure windowing systems. Those secure dtterms got this funky colour frame on them showing you which system compartment you are in, etc etc. It's pretty neat.

    HOWEVER, the marketing folks also added that the B2 evaluation process could take them several years and LOTS AND LOTS of $$, so they ended up selling HP-UX BLS 10.24 as a B1 system, aka. Virtual Vault.

    This is going to be a long journey, but I am still optimistic about it. What do you think?

    Yours,
    --Albert
  • I'm not sure that this is such a good idea. Splintering is not going to be good for BSD publicity. Perhaps a better-suited solution would be to create a project dedicated to securing the FreeBSD codebase to B1 standards.

    Don't call it another BSD, just fix what is there. Get your changes committed to the codebase. There are definitely times to fork and this is not one. I know they said that a lot of the code is going back into FreeBSD, but why should it ever be a separate thing, except maybe as patches until it gets committed?

  • Re:and come to think of it (Score:3)

    by Anonymous Coward on Sunday April 09, 2000 @08:37PM (#1142557)
    I work for a company that writes a Trusted Operating system so I have fairly good idea on what B1 takes.

    I cut data from file A, and paste it into file B. I can then control who has access to the information in file A by allowing them access to file B (which contains all the information from file A). This would be the case for ACL's, and all unix style permissions.

    MAC control on the other hand stops this. I can cut from file A (confidential A), and paste into file B(Secret A). I can only paste into file B if its label is the same or higher (this case higher). Now only be users cleared to see Secret A files can look at file B. I am not allowed to change the Security Label of the file. Further on most Trusted Operating systems almost all users are even allowed to change their effective Security Labels while logging in (that way you can't open a sensitive file, copy, and then paste into a file with a lower Security Label).

    What does MAC give you? Well combine this with breaking up of super user privilege (root) and you can setup a system where if Bind is compromised it does not matter. At the worst the Bind process is currupted, or sends out bad data. From where Bind is running no other part of the machine can be likewise compromised.

    (I would login, but I don't like cokies... except chocolate chip ones)

  • Current holders of big brother's seal (Score:3)

    by simpleguy ( 5686 ) on Sunday April 09, 2000 @07:50PM (#1142558) Homepage
    For those who might be interested, this is a listing of systems certified under the evaluation criteria, by order of rating. So, when do we see Linux there ?

    href="http://www.radium.ncsc. mil/tpep/epl/epl-by-class.html [ncsc.mil]

  • Orange Book (Score:3)

    by James Lanfear ( 34124 ) on Monday April 10, 2000 @03:09AM (#1142559)
    In anyone wants to read up on just what is required to make B1, the entire Rainbow Series on online [ncsc.mil]. The Orange Book itself is document 5200.28-STD [ncsc.mil].

    Fair warning, it's ~250K and definitely not light reading.

    © 2000 James Lanfear. All rights reserved.

  • ACL's are dead (Score:3)

    by UnknownSoldier ( 67820 ) on Monday April 10, 2000 @02:45AM (#1142560)
    > I hope these kids have a buttload of coders on board.. ACLs alone could take 18 months of serious coding..

    I sure hope not. Capabilities address secuity in a MUCH cleaner way then ACL's do.

    See:

    http://www.eros-os.org/essays/capintro. html [eros-os.org]

  • Re:and come to think of it (Score:3)

    by wowbagger ( 69688 ) on Monday April 10, 2000 @01:45AM (#1142561) Homepage Journal
    That problem is the very thing that makes it hard. However, it can be solved.


    Let's take your simple program that opens a "secret" classification file and opens a "confidential" (lower rated file), then copies the secret file to the classified file.


    The program starts life with a default classification inherited from the shell that started it (let's say this shell is top secret rated, just to make it interesting). When it opens the secret rated file for read, the system says "OK, you can read secret since your currently top secret" and the open succeeds. Then you try to open the other file as classified for write. The system says "well, you could do this, but I'd have to drop you to classified level. Oops, you have a file descriptor open at secret. Sorry Charlie, but no. E_BUTIWOULDHAVETOKILLYOU".


    Alternatively, let's say you do the classified file first, then the secret file. When you open the classified file for write, your process security goes to "classified", and then the open to the secret file fails.


    Now, think about all the various file descriptors a process has open, and think about making them all match in security. Now you see why getting a B rating takes a lot of work.

  • Re:and come to think of it (Score:3)

    by wowbagger ( 69688 ) on Monday April 10, 2000 @03:24AM (#1142562) Homepage Journal
    When the system drops your security to a less secure setting, that is only per-session, right?

    Actually, it's only per process. In other words, if you edit a "classified" file with vi, only vi gets knocked down to "classified". However, this is what makes it fun: what if you are running X, and you cut and paste from a secure document? Now you have to track the security level of the X cut&paste buffer. Again, this is why getting to a B2 security level is so hard: every time you think you've got it covered, another issue pops up.

  • BSD -> Star Trek (Score:3)

    by burtonator ( 70115 ) on Sunday April 09, 2000 @08:04PM (#1142563)
    Maybe we should name BSD releases after Star Trek and Vice versa: BSD: The Next Generation BSD: Boyager BSD: Deep BSD 9 or Trusted Star Trek or Open Star Trek :)

  • What "mandatory security" really means. (Score:3)

    by Animats ( 122034 ) on Monday April 10, 2000 @09:05AM (#1142564) Homepage
    B1 level requires "mandatory security". What this means is that the user can't do insecure things even if they want to.

    The classic DoD security policy is very simple: there are levels (UNCLASSIFIED, CONFIDENTIAL, SECRET, and TOP SECRET) and compartments (NOFORN, NATO, etc.) Associated with each file is one level and a set of compartments. Information is not allowed to flow downward in level or out of any of its compartments.

    You can easily decide whether any information flow is allowed, which is why this model can be enforced reliably. But it's not that useful to most people. For one thing, it's not about protecting systems; when military data is threatened, the military usually prefers it be destroyed rather than revealed. The military assumption is that if it is important, you have copies in multiple locations; after all, the enemy might bomb you. And few civilian organizations have an internal security policy that clear.

    Ken Biba tried to extend this security model to include what he called integrity. Integrity is the formal dual of security; data is not allowed to flow upward in integrity or into new integrity compartments. An integrity model might have levels such as (UNTRUSTED DATA, USER, ADMINISTRATOR, PERMANENT FIXED DATA). This is a tough model. For example, if you're running as administrator, you can't read anything except administrator-level data, and you can't run anything except administrator-level programs.. For example, running at administrator level cuts you completely off from any untrusted network. This is exactly what you want for security, but people hate this.

    The great thing about mandatory security is that it works. Anything you can't do directly, you can't do at all. It's the brutal simplicity of the system that makes it enforceable.

    But imposing this model on the mess of untrusted code that comes with any variant of UNIX is a very painful process. Most of that code will be usable only for non-secure work.

  • Re:OpenBSD? (Score:3)

    by Keith Maniac ( 136803 ) on Sunday April 09, 2000 @07:36PM (#1142565)
    Some moderator has a *great* sense of humor...

    I don't feel like being informative, so I will just flame you.

    Score: 2 (Informative)

    Trolls have nothing on this moderator. I salute you..

  • Re:creating another BSD could be bad (Score:3)

    by Keith Maniac ( 136803 ) on Sunday April 09, 2000 @07:50PM (#1142566)
    Well, it isn't splintered much more than "Trusted Solaris" is splintered from Solaris. In fact most commercial Unices ship a "trusted" version.

    The reason this work isn't being done to an existing BSD release is that B1 security brings a lot of hassle that isn't appropriate for many (or most) sites.

    The different BSDs exist for different goals, and until now B1 security hasn't been one of them.

    This is a perfect place to fork, since if you need B1 security, you can't do without it. If you aren't sure you need it, you probably don't want it.

  • Re:Stop the FUD! (Score:4)

    by kevin lyda ( 4803 ) on Sunday April 09, 2000 @09:49PM (#1142567) Homepage
    Finally, since the TrustedBSD code is being released under a 2-clause BSD license, the OpenBSD folks are quite free to incorporate the code, and in fact I expect them to do so.

    After all, that's what the BSD license is all about :-)

    actually, it's quite possible (under the bsd license) for the trustedbsd developers to offer binary only versions - thereby making sure that openbsd would not be able to incorporate those changes.

    the bsd license is not all about allowing other people to share your code since at some point someone can hide it away with their changes.

  • SGI doing this for Linux... (Score:4)

    by bbk ( 33798 ) on Sunday April 09, 2000 @07:41PM (#1142568) Homepage
    I went to the "SGI Linux University" a couple weeks back in Tucson, and they had a security segment at it, in which they described adding C2 and B1 level security to linux, and what would be required. They're probably a good company to do it, seeing as they have a lot of experience with Trusted IRIX. It's also prohibitively expensive to get the actual testing done, and having a big company foot the bill is very important.

    The greatest strength of open source - fast development time - is a burden on secure systems. Everytime something is changed, the whole needs to be reanalyzed so that no security breaches are created by the change. This is why pro-security distributions like OpenBSD are still using BIND 4.X and such - they don't have the time to reverify all the new packages and revisions.

    That said, certification means little until tested in the real world, but it can definitely help - look at OpenBSD's record!

  • Re:an open letter to Taco (Score:4)

    by gargle ( 97883 ) on Sunday April 09, 2000 @08:55PM (#1142569) Homepage
    You know, I almost wish that you're right, that there's a massive conspiracy by Taco/Andover/VA Linux to censor Slashdot. If that were the case, things would be easy to fix: Taco would see that what's happening will do more harm than good in the long run, and things can be changed.

    But it's worse than that. The problems arise from plain human incompetence:

    Clueless, uninformed moderators who don't bother reading the article in question before moderating ("moderate first, read later!"), moderate up posts that are plain wrong, or let their human biases show.

    Add to that boring editors who on top of not being able to spell or write, pointlessly editorialize in article postings, using /. as their own personal soapboxes.

    Don't forget the boring posters. You know, the people who keep posting on Slashdot. The regular posters are really boring (myself included). It was interesting at first, but the same old boring viewpoints just seem to get rehashed over and over.

    /. is getting very stale.



    ====

  • This isn't a new *BSD... (Score:4)

    by xXIshmaelXx ( 140748 ) on Sunday April 09, 2000 @07:46PM (#1142570)
    Whoever submitted and posted this story... Did you not read the website at all??? This isn't really some new *BSD. TrustedBSD is only a set of extensions implementing ACL's and a couple other security extensions to FreeBSD and is met to eventually be merged back into the FreeBSD cvs tree. It's only been setup to allow people to test this code before they put it into the tree.

  • Stop the FUD! (Score:5)

    by Anonymous Coward on Sunday April 09, 2000 @08:11PM (#1142571)
    I'd just like to try and head off some of the FUD thats already started to
    appear here. Firstly and most importantly, this is NOT a new version of
    BSD. Robert Watson is a FreeBSD developer who is building a set of
    extensions to FreeBSD which he is calling TrustedBSD. Some of this code
    is already in FreeBSD and other parts will follow. Perhaps all of it
    won't be for technical or other reasons, but this is only a set of
    patches to the code, not a separately developed OS.

    It's much the same as the situation with PicoBSD, which is a framework
    for building a one-floppy/embedded version of FreeBSD suitable for using
    as a dialup modem server, router, go-anywhere terminal, etc (PicoBSD
    is distributed within the main FreeBSD source tree).

    So why not use OpenBSD? Well, aside from the fact that Robert is a FreeBSD
    user and developer, not an OpenBSD one, the fact is that there's not
    much of a reason to choose OpenBSD - it's not inherently better suited to
    having usage auditing/capabilities/trusted system features. These features
    fit well with their philosophy policy, but they're just as appropriate for
    either OS. Put another way, there's nothing within the OpenBSD code at
    this point in time which would make the job easier/better than implementing
    it on FreeBSD.

    I should also point out for the record that FreeBSD is undergoing a similar
    code audit to the OpenBSD effort of a few years back, and is in the
    process of merging most of the OpenBSD code security fixes (it's
    been stalled for a little while due to release engineering efforts for
    FreeBSD 4.0, but I expect it to pick up steam again now that the
    developers can refocus their sights).

    Aside from default settings and kernel behaviour, there's becoming less
    of a difference between OpenBSD and FreeBSD (and in fact NetBSD as well)
    and I expect that trend to continue as time goes on. Everyone agrees that
    the often-cited "goals" of the three projects are all worthy things to
    pursue, the difference has just been in which order to pursue them, and so
    as time goes by the projects are expanding in the directions of the others.

    Finally, since the TrustedBSD code is being released under a 2-clause BSD
    license, the OpenBSD folks are quite free to incorporate the code, and in fact I
    expect them to do so.

    After all, that's what the BSD license is all about :-)

  • So I was wondering (Score:5)

    by aheitner ( 3273 ) on Sunday April 09, 2000 @07:44PM (#1142572)
    wtf "Orange Book B1" was. I went and found the following defin ition [jos.org]:


    labeled security protection
    The B1 system class. B1 (and higher) systems support mandatory access controls. The system architecture must more rigorously separate the security-related portions of the system from those that are not security-related. Documentation must include a model of the security policy supported by the system. It need not be a mathematical one, but it must be a clear statement of the rules enforced by the system's security features. Testing is more stringent.


  • and come to think of it (Score:5)

    by aheitner ( 3273 ) on Sunday April 09, 2000 @07:57PM (#1142573)
    now that I've read all the little side-definitions ...

    the specs say you must rigorously separate the security-related portions of the system from those that are not security-related and Documentation must include a model of the security policy

    Which really makes it sound like it's a very formal thing. But actually, [the security model] need not be a mathematical one, but it must be a clear statement of the rules

    So ... you have to have fine-grained control of everything that can affect system security. You have to define in a carefully documented hierarchy how the various security levels interact, and exactly what rights each one has. Doesn't sound too bad.

    The Mandatory Access Controls (MAC) really sounds like a carefully documented ACL-set; it restricts access to system objects (eg. files, directories, devices) based on the sensitivity of the information in the object (represented by the object's label) and the authorization of the subject. Additionally, the system enforces the policy; users do not have the discretion to share their files. Slightly more compulsive than typical ACL rules, but nothing unreasonable.

    It seems like you'd actually want to start with OpenBSD and use a very traditional POSIX style to approach this. The real work is in the documentation.

    That said, save from the "rigourous testing" there's no hard guarantee this system is any safer. I'm not particularly impressed by this spec over the state of any reasonably secure UNIX. The real issue is not compliance with the spec itself, but how good your (documented) security policy is (and of course how well you've actually implemented it!). This whole spec really sounds like (imnsho) a way for you to bring in overpaid worthless consultants to read your policy/procedures, do some meaningless tests, and issue you a silly certification.

    Shades of ISO9000, anyone?

    This "Orange Book" sounds like a good idea at the beginning. But every definition in that glossary is at the level I would use to talk to my mother about computers: leave out all the subtleties or technical considerations. I think a system like WinNT could pass those specs with flying colours (if indeed it hasn't already) and still (duh) suck.

    My $0.02.

  • Re:and come to think of it (Score:5)

    by Scola ( 4708 ) on Sunday April 09, 2000 @11:08PM (#1142574)
    No, you don't understand what you're talking about. Both UNIX and NT are C1 systems. They offer the traditional discressionary access control: file permissions or acls. B1 is fundamentally different. MAC may sound like ACLs with documentation, but it is not. In DAC a file's access is controlled at the discression of the user (hence the name). Basically, if you and I are on the same system, I can let you see my file. In MAC, if you shouldn't be seeing my file, you won't. The system assigns a sensitivity label to the file. Think of it like the difference between a file in your filing cabinet and a file at a military institution. If you have a file in your cabinet that you wrote, you can let me read it or write to it if you desire. If it's at a military base, and its stored there, you need a certain clearance level to enter where the file is and read it. If I have Top Secret clearance, and you only have Secret, no matter how much I want you to read the file, you can't, and I can't make you Top Secret. It's a forced analogy but you get the point.

    Documentation is required to confirm correctness and to specify how requirements were met. There's a lot of modification to the code.

    In truth, I'd be surprised if FreeBSD wanted this in the core OS. A B1 level of security can get quite annoying in situations where security is not your paramount goal. There is a lot of extra overhead to do MAC checks and MAC intentionally sort of puts people in a prison.

    The Orange Book is not simple either, and reading the glossary is not a substitute for reading the book (which I have not). It's very thick and extremely detailed.

  • They've bitten off a lot, here.. (Score:5)

    by Blue Lang ( 13117 ) on Sunday April 09, 2000 @07:26PM (#1142575) Homepage
    Unless there's some secret project I don't know about, I hope these kids have a buttload of coders on board.. ACLs alone could take 18 months of serious coding..

    Also, it doesn't really matter if they use FreeBSD or OBSD as a base - these are all extenstions. In other words, for B1, you're not going to be running sendmail anyways, so having your daemon code audited aint gonna matter that much.

    I do wish they had started with OBSD, tho. They prolly chose FBSD because of personal loyalties to someone(s) on the FBSD project - or because of the opposite on the OBSD project. :P

    I'm sure Theo will re-write everything they do, anyways. :P

    Their web site sucks, it's just a bunch of links pointing to the same non-existant docs. This looks like something that someone started like, last thursday. :P

    --
    blue

  • AT&T System V/MLS was First B1 Unix System (Score:5)

    by billstewart ( 78916 ) on Sunday April 09, 2000 @10:20PM (#1142576) Journal
    AT&T System V/MLS was the first B1-rated Unix system, developed by Bell Labs in the mid-late 80s. I wasn't one of the developers, but I worked with the system porting applications and convincing people to use the stuff and evaluating what a secure operating system would do in various environments. IIRC, it was certified on the AT&T 3B computers, but it also ran on Intel 386 PC platforms.


    System V/MLS implemented Mandatory Access Controls, but didn't split root into least-privilege. The MAC stuff was wedged into the group permissions, with some bits stolen for security level (I think 0-7) and some for security groups, but a few bits left for Unix groups. This left most of the Unix data structures unscathed, but it was enough, and you could buid ACLs by creating groups that had the right people in them. There were a few modified tools for building groups with, and the rules that control what GID a file has when it's created were seriously hacked. (It looked sort of like the BSD feature that gives files the GID of the directory they're in.)


    Mandatory Access Controls were designed for the military's SECRET/TOPSECRET/UNCLASSIFIED worldview, which doesn't match most non-military applications, but they turn out to be quite useful tools for making the system more secure for regular applications. You create a "System Low" classification group and put most of the standard software and critical configuration at that level, and nobody can write to it because MAC protects against higher-classification processes writing information that could be a security leak. And you create a "System High" group for logfiles and such, which nobody can read but loggers can append to.


    Networking was very limited - this was in the days before anybody had a good solution for any of the Red Book requirements - trusting messages from other machines and trusting other machines to protect your messages require common administration (which didn't fit the Orange Book certification models well), or else require doing the right things with cryptography (which the NSA had a fairly heavy lock on, plus they didn't want to trust military secrets to civilian cryptography, so it wasn't politically usable even when the technology was good enough.) So we didn't have TCP/IP built into the kernel, but you could do things like UUCP over hardwired lines, as long as you ran different UUCP processes and directories for different security levels and dedicated RS232 ports to specific security levels.


    Least privilege is one of the controversial areas, but it was possible to do B1 without it. It's a bit easier in a System V environment, where mail runs as Group Mail and uses setgid programs instead of needing to run as root, and of course if you don't have TCP/IP running you don't need as many privileged daemons (many of which run as root simply because low TCP/UDP port numbers are required to be root in BSD environments.)


    Covert channel analysis was a B2 feature. It wasn't very possible back then - there are just too many ways to leak information, like high-classification processes grabbing and releasing disk space in Morse Code or whatever. PCs are 2-3 orders of magnitude faster - it's much harder to limit the speed of those channels today.


    There were a few other magic things - a Secure Attention Key is a B3 requirement that gives you a secure, unforgeable communication with the login system; this basically used Ctrl-Alt-Delete on PCs, and I think Break on dumb terminals, which weren't able to be stolen by user processes. And there were some shadow directory things, so a low-classification user couldn't see higher-classification files or directories, but a higher-classification process could see high and low files.

  • openbsd v. the world (Score:5)

    by The_Messenger ( 110966 ) on Sunday April 09, 2000 @09:44PM (#1142577) Homepage Journal
    i have to clarify something, after reading too many of the same posts about openbsd. many people are under the impression that openbsd is the same as free- or netbsd, and it just comes packaged with more crypto software.

    actually, the encryption mechanisms are built right into the operating system, in such a way which would make it illegal to export, if the project were based in the us (which it obviously isn't).

    this cryto-integration is what makes openbsd unique.

    so yes, you could make freebsd or linux "as secure" as openbsd*, but you won't get crytography on the same level. that's why cypherpunks like myself find openbsd to be such a worthy project.

    *(if you can really measure security in such an immature way. security is as much a function of proper administration as it is software. "security is a process, not a product" (paraphrased))

    the orange book (and most of the other books in the rainbow series) provide standards for trusted (ie secure) operating systems in different levels of government and military facilities. "trusted" means just that -- a system of trusts, to guarantee that you can trust data to be valid.

    trust systems and crytography are two different things.

    for instance kerberos [mit.edu] (my favorite trust/authentication system) is NOT a type of encryption, as many here seem to think, but a trust system which USES encryption as part of its processes. kerberos in particular is interesting because it authenicates (gains trust) with multiple methods, including passwords, box address, et cetera. you can put the authenication on one server, the password database on another, and do all sorts of devious little things to make it *very* difficult for interlopers. read some of the MIT material and you'll probably be as impressed as i was when i first began studying it.

    the best introduction you can possibly find is this one [mit.edu], which explains kerberos' theories of authentication in the form of a short play, where two developers are designing an authenication system. it shows exactly why kerberos has to be as complex as it is, to establish true trust between hosts.

    kerberos can use any type of encryption to do its work. the system isn't tied to one method, even though it usually seems to be implemented with a DES-derived algorithm. if you need maximum data integrity, go with 3DES. if you need speed, use blowfish. do whatever you want.

    i seem to have gotten quite a ways off-topic. oh well. just remember that openbsd is NOT just freebsd with the evil daemons turned off.

    openbsd users can back me up on this. theo really is a paranoid son a a bitch, and i congratulate him for it. the point is, openbsd probably ALREADY qualifies for most of the rainbow book certifications. plus, theo and crew have a track record of finding and fixing security bugs long before the "competition".

    probably the biggest thing holding it back is the lack of smp support, which should be changing in the next year. i'd like one of the openbsd core team members to comment on this, if possible. can you guys use any of the freebsd 4.0 code for the smp kernel? freebsd 4.0 really has some decent locking mechanisms, among other things. if you could take advantage of their work, openbsd-smp could really hit the ground running. god bless the bsd license!

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close