TrustedBSD Announced
Posted by
Nik
on Mon Apr 10, 2000 12:13 AM
from the nice-logo dept.
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
|
Log In/Create an Account
| Top
| 100 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Re:and come to think of it (Score:3)
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)
href="http://www.radium.ncsc. mil/tpep/epl/epl-by-class.html [ncsc.mil]
Orange Book (Score:3)
Fair warning, it's ~250K and definitely not light reading.
© 2000 James Lanfear. All rights reserved.
ACL's are dead (Score:3)
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)
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)
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)
What "mandatory security" really means. (Score:3)
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)
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)
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)
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)
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)
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.
====
This isn't a new *BSD... (Score:4)
Stop the FUD! (Score:5)
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)
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)
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.
Re:and come to think of it (Score:5)
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)
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
AT&T System V/MLS was First B1 Unix System (Score:5)
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)
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!