Date: Thu, 16 Oct 1997 00:04:00 -0600 (MDT) From: Wes Peters <softweyr@xmission.com> To: Mike Smith <mike@smith.net.au> Cc: chat@freebsd.org Subject: Re: C2 Trusted FreeBSD? Message-ID: <199710160604.AAA12373@obie.softweyr.ml.org> In-Reply-To: <199710150043.KAA00590@word.smith.net.au> References: <199710141601.KAA10425@obie.softweyr.ml.org> <199710150043.KAA00590@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith writes:
> >
> > There are no incidences in which pages are returned to you with previous
> > random cruft left in them?
>
> There shouldn't be, no.
In that case, I assume fill-on-allocation would be suffice. Of course,
you'll have to *prove* there aren't any cases. ;^)
> > And besides, zero-filling memory isn't sufficient, it has to be
> > overwritten a number of times to make sure now residual information can
> > be obtained. These standards date back to core and even mercury-wire
> > memory. Yes, I've actually worked with computers that feature *both* in
> > my career. ;^)
>
> If you can suggest how one goes about obtaining "residual" information
> from a saturated logic device in a synchronous memory subsystem, I'd be
> very interested in hearing it.
>
> Or is this more specification paranoia?
Of course it's specification paranoia, that's exactly the point.
Several different people in this discussion have been trying to discuss
the INTENT of the specifications, and/or enforce USABLE standards.
Neither of these apply, this is a standard developed by the US
Department of Defense and National Security Agency, er, excuse me, No
Such Agency. They don't have to make sense, nor do they have to be
usable, but you still have to follow them.
On the other hand, consider that your bzero is used to zero-fill disk
pages as well, and you *CAN* recover latent information off a disk, even
after it has been overwritten several times, if you try really hard.
Come to think of it, I think this is probably why most secure UNIX
systems do overwrite on free rather than overwrite on allocation. Every
disk block that is returned to the free list has to be overwritten
before it can be given to any new process, including via the disk device
drivers.
This kind of stuff gets really messy, and requires a lot of thorough
work to get right. I suggest for anyone who is really interested in
this, see if Sun still has any white papers, design notes, etc. for
their C2-secure SunOS; they might give you some insight into what
changes would have to be made to secure FreeBSD.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.xmission.com/~softweyr softweyr@xmission.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710160604.AAA12373>