Date: Mon, 13 Oct 1997 19:07:00 -0500 From: dkelly@hiwaay.net To: freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <199710140007.TAA10222@nospam.hiwaay.net> In-Reply-To: Message from Christopher Petrilli <petrilli@amber.org> of "Mon, 13 Oct 1997 17:09:09 EDT." <199710132110.RAA29578@dworkin.amber.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(trimmed to -security only) Christopher Petrilli writes: > > THat having been said, there is one other requirement that would need to > be addressed: > > * Object Reuse (2.2.1.2) > > THis is defined as follows: > > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produced > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. I haven't been able to prove this isn't done already in FreeBSD. Had to write for our security officer some trivial code to explore and demonstrate what happens when a process steps outside of its allocated memory. Ran it under Solaris 2.5.1, Irix 6.2, and FreeBSD 2.2. Everything (that didn't "segmentation violation") came up zeros. Now I'd be the last person to claim this proved anything other than the fact that I'm able to write programs that signal-11. :-) Remember finding in the documentation for Trusted Irix where they were discussing item by item how Trusted Irix meets spec (NISPOM or Orange book, I forget) there was a specific mention that Irix did not clear objects on release, but always cleared prior to allocation. The certifying agency accepted this deviation. As others have mentioned, one doesn't really have a C2, B1, or A1 system unless one exactly replicates the certified system, hardware, and configuration. From what I've seen a Security Officer outlines what is expected in the way of security features and procedures. Then expects the adminstrator of the system to formally document how the system will comply. So SGI and Sun write security manuals with an eye for being quoted. Depends on your environment, but a Security Officer may accept the claims of an administrator that his documented procedures and software meets the security requirements, even without formal compliance certification. The One Thing FreeBSD lacks that has prevented me from attempting to place it in a particular environment is audit trails. Specifically we only need to log all "access denied" failures, such as the above mentioned segmentation violations, file access, priviledged opcodes, etc. Don't believe I was required to, but did anyway, log setuid transitions. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710140007.TAA10222>