Date: Wed, 15 Oct 1997 11:35:05 +0930 From: Mike Smith <mike@smith.net.au> To: "Christopher G. Petrilli" <petrilli@amber.org> Cc: chat@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <199710150205.LAA00894@word.smith.net.au> In-Reply-To: Your message of "Tue, 14 Oct 1997 21:56:28 -0400." <Pine.BSF.3.96.971014214640.2865K-100000@dworkin.amber.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Please note that I asked that this be moved to -chat, and I have taken it there. This isn't relevant to the charter of -security anymore. > > The only methods for obtaining the previous contents of a storage > > location involve physical analog access to the hardware, and if you > > have this then system security has already been compromised because you > > could have recorded the original value when it was current. > > Security is an all-encompassing thing, not electornic, not physical. > And without verified architecture, ther eis no "proof" that the only way > to get access to the storage location is via physical access. Remember, > that's why it costs a lot of money to build verified systems, one has to > build a boolean algebra description of the system that is provable, rather > than just "good enough." Whoa, hold it right there. We have already been informed that the hardware platform is subject to the certification process, obviously to ensure that all possible access to a storage location are subject to the approproiate security controls. > While things like Van Eck devices can be used for real-time access, hence > the TEMPEST and ZONE restrictions on various foreign installations > (TEMPEST is no longer mandetory for US classified, and ZONE is optional in > many cases), these do not deal with residual data. My issue was that > residual data can be read via various methods. My point is that these methods are inherently not available on a certified platform, and if the physical access to provide them *was* available, much simpler techniques could be used that would *not* be defended by zeroing the stable door after the horse has been copied. "Residual data" is not the issue here; the suggestion was that an object returned to the allocator after use by a subject should/must be overwritten multiple times at the point it is returned. Within the bounds established by the certification of the hardware and environment, this is redundant and inefficient. > I believe that it is totally acceptable > to do a single write over RAM, but that disk storage SHOULD be dealth with > seperately with an appropriate pattern. ... so here you are basically agreeing with me? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710150205.LAA00894>