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!"

Comments

Re:Stop the FUD!

[kevin lyda]

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

[bbk]

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

[gargle]

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

[xXIshmaelXx]

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!

[Anonymous Coward]

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

[aheitner]

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.

and come to think of it

[aheitner]

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

[Scola]

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

[Blue Lang]

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

[billstewart]

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

[The_Messenger]

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 (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!