Slashdot Mirror
TrustedBSD Announced
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!"
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?
Nope. DG/UX has offered a B2 security option 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 :-)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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...
US Citizen living abroad? Register to vote!
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.
US Citizen living abroad? Register to vote!
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:
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.
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!
__________
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
That claim was removed from the Multicians website (possibly as the result of a
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.
__________
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
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?
iSKUNK!
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
This is Unix. Stop acting so helpless.
-russ
Don't piss off The Angry Economist
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
Don't piss off The Angry Economist
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... ?
25% Funny, 25% Insightful, 25% Informative, 25% Troll
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.
If it was said on slashdot, it MUST be true!
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.
If it was said on slashdot, it MUST be true!
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.
/have/ been OS's other than Multics that achieved B-level.
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
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!
Weapons of Mass Analysis
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.
Salocin.com
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?
"Have some dignity" --Mickey Knox
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)
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
Fair warning, it's ~250K and definitely not light reading.
© 2000 James Lanfear. All rights reserved.
> 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
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.
www.eFax.com are spammers
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.
www.eFax.com are spammers
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 :)
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.
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..
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.
US Citizen living abroad? Register to vote!
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!
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.
/. as their own personal soapboxes.
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
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.
====
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.
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
wtf "Orange Book B1" was. I went and found the following defin ition:
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.
now that I've read all the little side-definitions ...
... 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 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
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.
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..
:P
:P
:P
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.
I'm sure Theo will re-write everything they do, anyways.
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.
--
blue
i browse at -1 because they're funnier than you are.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 (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, 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!
--
I like to watch.