Date: Tue, 14 Oct 1997 21:02:25 -0500 From: dkelly@hiwaay.net To: Wes Peters <softweyr@xmission.com> Cc: Christopher Petrilli <petrilli@amber.org>, security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <199710150202.VAA21041@nospam.hiwaay.net> In-Reply-To: Message from Wes Peters <softweyr@xmission.com> of "Tue, 14 Oct 1997 09:56:38 MDT." <199710141556.JAA10419@obie.softweyr.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Wes Peters writes: > > Nope. The Sun C2 security system used only group controls. This is the > U.S. government, there are *no* concerns about practical enforcement. > In their view, if any mechanism is provided, their slaves can be beaten > into writing procedures that will correctly use the supplied mechanism, > clumsy as it may be. Yup. The System Security Custodian has to document all this stuff and submit it for review before the government person who signs off on it will agree to an initial inspection. Then you get grilled on how well you know your own procedures. And are expected to demonstrate the systems security features and your mastery of them. SGI also *claims* to meet C2 with only Discressionary Access Control, in other words, "plain old Unix user and groups." Note emphasis on "claims", as they developed Trusted Irix for B1 or thereabouts and were somehow prevented from having more than one system under test. And never submitted a system for C2 testing. So they provide a white paper detailing how plain old Irix with the addition of the Trusted Irix auditing system meets the intent of C2. This has been Good Enough to use plain Irix with audit trails at work. http://www.sgi.com/Support/security/c2_in_5.3_6.1.ps is the white paper I'm talking about. We quoted it for Irix 6.2. > > 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. > > Has to be deallocated, unless you want to maintain ownership credentials > of the deallocated pools. The act of returning a block of memory to the > "free" pool changes its ownership. There is an existing standard for > reclaiming memory in C2 systems. If I remember correctly, you have to > overwrite each bit with successive 1 and 0 for 100 cycles. This is > pretty cpu intensive, but can be done pretty easily by modify sbrk and > friends. I guess in the post 2.2 world, it would be munmap that gets > mangled, right? I've never seen the "100 times overwrite" requirement. The act of writing a zero to memory that is parity checked in hardware should satisfy the spirit of the requirement. If writing the zero didn't work, it fails on first read. In the above document, SGI points out "clear before reallocate" was approved when they tested Trusted Irix for B1, so they claim the same is good enough for plain Irix at C2. -- 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?199710150202.VAA21041>