Jeff Marshall <jeffrey_g_marshall <at> yahoo.com> writes:
>
> Has anyone from the Xen community been following the
> development of the draft "U.S. Government Protection
> Profile for Separation Kernels in Environments
> Requiring High Robustness", which has lately been
> discussed at Open Group?
>
> http://www.niap.nist.gov/pp/draft_pps/pp_draft_skpp_hr_v0.621.html
>
> The concept of a separation kernel in that protection
> profile has a fair amount of overlap with Xen,
> although the match is not complete (i.e. configuration
> data is static in the SKPP). Still, the PP has some
> interesting xen-relevant bits if you're willing to
> wade through the boilerplate that permeates protection
> profiles. In any case, while I doubt Xen will ever
> pursue Common Criteria evaluation under this profile,
> the security-concious portion of the Xen community
> might get something out of reading it.
>
> Regards,
>
> Jeff Marshall
> jeffrey_g_marshall <at> yahoo.com
>
Jeff,
We haven't necessarily been "following" this PP, but we are quite aware of it. I
would also add that SKPP seems to be designed (by NSA and others) in part to
support their MILS (Multiple Independent Levels of Security) "separation kernel"
concept. So, what is MILS? It's essentially the disaggregation of system
security into manageable components that can be evaluated separately -- e.g.,
secure service partitions. Here's a couple of other descriptions from NSA:
"Instead of placing all security requirements in this security kernel we want to
share the responsibility for security with the application layer. In the old
Orange Book, i.e., TCSEC, the definition of Reference Monitor was: non
bypassable, always invoked, tamperproof, and evaluatable. What we want to be
able to do is to create a layered reference monitor architecture. The
responsibility of this security kernel or separation kernel is to enable the
middleware and application layer entities to security manage, control, and
enforce their own security policies. We want an architecture that allows the
security kernel to share the responsibility of security with the application."
"The MILS architecture was developed to resolve the difficulty of certification
of MLS systems, by separating out the security mechanisms and concerns into
manageable components. A MILS system isolates processes into partitions, which
define a collection of data objects, code and system resources. These individual
partitions can be evaluated separately, if the MILS architecture is implemented
correctly. This divide and conquer approach will exponentially reduce the proof
effort for secure systems. To support these partitions the MILS architecture is
divided into three layers: Partitioner, Middleware Services, and Applications."
Note however that SKPP is targeting fairly high levels of assurance (EAL6+).
While sHype does address the same/similar concepts as those addressed in SKPP,
achieving that level of assurance would be quite a challenge for anyone (IMHO).
Regards,
-Ron
Ronald Perez
Manager, Secure Systems
IBM Thomas J. Watson Research Center, Hawthorne, NY
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home