Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Oct 1997 12:37:06 +0100
From:      Colman Reilly <careilly@monoid.cs.tcd.ie>
To:        "Christopher G. Petrilli" <petrilli@amber.org>
Cc:        security@freebsd.org
Subject:   Re: C2 Trusted FreeBSD? (and what do we want anyway?)
Message-ID:  <199710151137.MAA20954@monoid.cs.tcd.ie>
In-Reply-To: Message from "Christopher G. Petrilli"  dated Tuesday at 21:56.

next in thread | raw e-mail | index | archive | help
     On Wed, 15 Oct 1997, Mike Smith wrote:
     
     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."
Heh. Note that even A1 requirements for verification (or European E6) fall
far short of verification. They boil down to having a formal model of wht
you're trying to do and a semi-formal demonstratioin that the code matches
the model. 
     
     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.  
Not from RAM under the conditions we cre about. If they've got your RAM
you're probalby already well screwed.
     
     
     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.
This is a good idea, but watch the Linux people scream at our performance
then. :-)
     
     The pattern is designed to stabilize the magnetic properties (remmeber, no
     single magnetic domain is totally independent of the ones around it) by
     exercising them in a specific order.  This is hardly paranoia, but a
     provable physical property.  Why do you think you can recover data off of
     an erased disk? :-)
This is assuming some physical organisation of the disk I assume?

Now, this discussion all brings to mind  more basic question. Let's pretend,
just for the moment that we thought an assured high-level of security was a 
good idea. 

Let's also pretend that we don't care about actual certification - we're
unlikely to ever achieve certification if only because we fail the
administrative requirements as far as I can see ... lot's of very anal
non-functional requirements that are appropriate if your source code is
secret, but inapplicable if your source code is widely available. 

Now, in that situation, what security claims would we like to make? What
model of security beyond what we have is appropriate?

I like the ideas of projects, security levels and mandatory access control.
My favourite use for it would be to place the web server and all it's minions
in one project and everything sensitive somewhere else. Apply controls as
appropriate, and I'm much happier a compromise of my web server isn't going
to get my password file or anything useful like that.

I also like ACL's, under some suitable model. Incidentially, I'm probably
capable of modelling the behaviours of proposed ACL structure fairly rapidly,
so we can play with policies and models and see what happens without actually
writing any real code. Abstract prototypes are fun.

I'd also like the sort of control's discussed for sockets previously. This
would remove so much of the requirement for root that servers have that it
would be highly worthwhile. Of course, we should apply ACL's to that too.

This would be part of extending explicit controls to all objects rather
than just files as is currently the case. 

Of course, we should meet C2 anyway, and hope someone certifies it free of
charge and effort for us. :-)

On a side note, I was suggesting to Mike Smith that it might be worthwhile
including a configuration sanity checker in the juliet configuration server
he's working on. (Mike, my thoughts on that have changed a bit - I'll e-mail
privately later.) This would be a nice selling point for the OS.


Colman

[My second rant this week. Must be the Category Theory that's doing it to me.]



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710151137.MAA20954>