Talk:Multilevel security

From Wikipedia, the free encyclopedia

Contents 1 MLS isn't a model 2 Definition of MILS and MLS 3 Requested move 4 Vendors are misleading readers

[edit] MLS isn't a model

MLS itself isn't a model - it's either a mode or a mechanism, and there are lots of models associated with MLS, but MLS itself isn't a model. I suppose it could be in the models category, but it belongs in the top level category, too. Rick Smith 23:24, 18 April 2006 (UTC) I agree, that is so obvious (I hope) that I just moved it.

John 17:38, 30 October 2006 (UTC)

[edit] Definition of MILS and MLS

Overall this is a definite improvement to the article - my last edit added material about MILS/MSL in order to correct what looked like commercialization to me. The new material, especially on NetTop, rounds things out nicely.

However, I'm skeptical about some of the new material. I don't see MILS as being a generalization that incorporates MLS, and I don't think Mark Van Fleet (or his Powerpoint) intended to convey that. MLS, as described in the Wiki article (and as it has been used traditionally in user communities, though not so much by people who understand the security technology), is a Holy Grail of clean, painless data exchange without the risk of compromise. However, according to security technologists, MLS is a mechanism that implements Bell-LaPadula, or something like it. MILS is a technical-architectural strategy for implementing MLS data sharing. Van Fleet's Powerpoint about MILS talks about MLS in technical terms (implementing BLP) and classifies MLS technology in that vein. In that sense, it's talking about a narrower definition of MLS than is addressed in the article.

Incidentally, it's ahistoric to refer to periods processing as an "advance" in MSL. It's what people did back in the '50s and '60s and '70s when they couldn't afford separate computers to process data at different classification levels. Its inefficiency essentially led to the push for MLS.

Maybe I should do a "history" section.

(When you do - SACDIN was renamed SACCS DTS in the late 80's and it is still operating MLS - also not I386 but IBM Commercial Series/1)

Rick Smith 01:46, 7 November 2005 (UTC)

MILS does not seem to belong in the MLS article because MILS is contrary to MLS. The objective of MILS is separation of domains, that is, to prevent interaction between domains. Literally, it enforces independence among the levels of security. Independence negates the hierarchical nature of the domains implied by the word ‘levels’ so that the security domains might as well not have levels (a lattice that is not ordered). A more descriptive name might be Multiple Independent Domains of Security.

Because MLS permits flow from low domains to high domains it is contrary to the MILS objective. At its foundation a MLS kernel must first separate domains then allow selective (BLP flow) interaction. MLS kernels are actually built this way, they have domain separation mechanisms and access control mechanisms that support controlled channels between the domains. MILS can only support MLS by providing the ‘separation’ mechanism for a trusted application on top of it that provides the acess control application acting as a traffic cop where all interdomain flow passes through it. This has severe performance issues compared to the old style secure operating systems, which themselves were criticized for performance.

Furthermore, I am skeptical that MILS can ever achieve high enough assurance to really warrant practical MLS trust. MILS is pursuing a (draft) protection profile (Separation Kernel Protection Profile) that takes a top down approach to maintaining a domain for its own execution. It formalizes the top level objective of ‘separation,’ then addresses the kernel’s domain independence, and finally just assumes the existence of whatever hardware functions that are needed to support it. (I assume it takes that approach to facilitate portability among microprocessor HW.) The ‘old school way’ (e.g. SCOMP to Blacker) was to characterize the target microprocessor HW operations then formally describe kernel’s own domain isolation mechanisms built on those operations, building up the kernel off the HW foundation. The old school way makes porting to new HW a real pain but it is simple minded and proven, the SKPP HW portable approach is at best unproven.

John 01:51, 26 October 2006 (UTC)

[edit] Requested move

This page should be moved to "Multilevel Security" which omits the hyphen.
The hyphen is not consistently used, and I think its presence makes the article harder to find.
As a beginner I don't know what the protocol is regarding hyphenating compound words like that. -- Cryptosmith 19:20, 6 July 2005 (UTC)

• Oppose. – AxSkov (T) 07:15, 14 July 2005 (UTC)
• Oppose. The term/concept is hyphenated in documentation. CHoltje 20:40, July 14, 2005 (UTC)

It was requested that this article be renamed but there was no consensus for it be moved. violet/riga (t) 16:59, 17 July 2005 (UTC)

The movement of this article has been completed as of November 2006. Personally, I find the new title to be unhelpful, as Multi-Level Security (MLS) is a standard representation within the target audience; however, I abide by the decision. Jamie 15:46, 6 November 2005 (UTC)

• OK, let this be a lesson to me in contributing to Wikipedia - I did the move without ever being aware of opposition to it, and I'm not sure how it happened that way, since I was obviously aware of the existence of the discussion area. In defense of the disputed move, however, let me point out that I've spent a lot of time working on multilevel (multi-level) security and I have seen no clear consensus as to whether it should be hyphenated or not. In my own writing on the subject I've used it both ways, but I'm not fond of unnecessary hyphens. Personally I don't care if someone else wants to move it back. I notice that Google gets about 1M hits on "multilevel" security and 1.9M on "multi-level" security. Many of the same articles come up in both searches, even with quotes. Rick Smith 23:22, 6 November 2005 (UTC)

[edit] Vendors are misleading readers

Vendors are claiming their products provide MLS solutions citing Common Criteria evaluation of their products to Controlled Access Protection Profile (CAPP) at elevated levels (like EAL-4 and EAL-5 although CAPP is an EAL-3 Protection Profile.) The problem is that CAPP fails to require that a kernel maintain a domain for its own execution, which is fundamental to the objectives of MLS. So it doesn't matter what the EAL level, a CAPP-certified EAL-7 kernel is not worthy of MLS trust.

Furthermore in its introduction CAPP cites Orange Book C2 as its basis, which is not valid for MLS. Furthermore in its introduction CAPP warns users that CAPP does not address enough self protection functionality to protect itself against subversion by users. This means it depends on the users themselves to enforce security on themselves, a notion contrary to MLS. Labled Security Protection Profile enforced by a CAPP-certified kernel is misleading people into thinking they can depend on LSPP functions, when the underlying CAPP-certified kernel is unable to protect LSPP functions from subversion.

Vendors need to stop using this article as a platform for misleading readers.

John 01:03, 26 October 2006 (UTC)

I'm not necessarily disputing what you're saying, but I'm hoping to learn more. If I'm reading what you're saying correctly, any operating system that is successfully evaluated to CAPP is by definition incapable of being an MLS OS -- even if it is also evaluated to LSPP? I think what would help me here would be an example of an OS that you consider to be valid for MLS, whether it is CC evaluated, and if so which PPs it's evaluated against. Thanks --NapoliRoma 13:27, 26 October 2006 (UTC)

Well, CAPP certification doesn't quite guarantee it is incapable of MLS, but CAPP is not evidence of MLS capability. LSPP evaluation doesn't address kernel self protection so LSPP certification isn't a plus in the strength dimension, dispite the misleading way it is shown (EAL4+). LSPP is just some label management capabilities, they run on the kernel and depend on it for protection from corruption. So LSPP is not valid for MLS unless it runs on a kernel certified to an MLS PP.

Kernel self protection is hard to get right because of the HW/SW interactions. GEMSOS is being marketed as an MLS capable kernel, and I suspect it is capable of MLS but it is not now CC evaluated, partly because no one wrote a PP requiring that much strength. GEMSOS is a Pentium port of the old 90's 386-based Blacker kernel certified A-1 (good for TS, S, C and U) and still running in the dark corners of a big black building. Blacker was fast and adgile for a SoS, and very strong. All the successful A-1 evaluated products were 386-based for HW reasons. John 06:01, 27 October 2006 (UTC)

So if the problem isn't that an OS is evaluated to CAPP, but that it isn't evaluated to an MLS PP, wouldn't it make more sense to say that? The discussion here on the talk page appears to be more accurate and on point than what's on the page currently. It would also seem to make sense to add something about LSPP not being a sufficient PP to assure MLS. I think it would also be useful to have some sort of citation that documents the assertion that labelled security is not equivalent to multilevel security, as my impression is that this is a very common assumption. --NapoliRoma 00:42, 28 October 2006 (UTC)

Yes, it would make more sense. That is a good idea, I was planning to think of that. (not)

I have not run across the LSPP = MLS assumption. Can we just add clarification of any crazy thing we think is misunderstood? I'm good with that, I gave it a try. I am concerned that this is turning into too much of a CC tutorial, where does that end?

Still, my real opinion is that the latter sections are little more than a promotional plug for Sun and BAE and should be deleted pursuant to the promotional policies. They aren't MLS and are excessively misleading. I tried to turn them into examples to make them MLS relavant. Unless someone objects, I may just remove them. John 03:06, 28 October 2006 (UTC)

If they aren't MLS, they should be removed. I don't think there's any ambiguity there. I also think that if they remain, they should remain as simple examples, rather than anything that looks like a promotional brochure.

However, it's still unclear (to me) that they're not MLS. They're certainly used in MLS applications, they have what purports to be MLS functionality, and the products have each gone through Orange Book B-level evaluations in the past. There still seems to be an implicit or even explicit proposition that the act of receiving CC evaluation against a CAPP profile has somehow negated their previous evaluations, and there also seems to be a sentiment that going for high EAL evaluations is subterfuge on the part of the vendors. (Similarly, there's an implication in the article as currently written that an OS evaluated to C2 cannot also be evaluated to B1 or higher.)

Maybe the article should say something like: "Sun's Trusted Solaris and BAE Systems' XTS-400 are offered as commercial MLS operating systems; however, neither has been evaluated against MLS protection profiles" and leave it at that. Either that, or remove any reference. --NapoliRoma 18:24, 30 October 2006 (UTC)

It is very clear to me they are not MLS. You make some thoughtful points: One is that the MLS capability may still be there if it was there earlier, even if it is not assured by the current CC certification. Technically, previous version certification doesn’t count, but what about practically? All I can say here is that I think self protection would be the issue, and if it ever was really there, then the RAMP program is a low cost path to maintain the B-level cert if they really retained adequate self protection capability in tech upgrades. So why didn’t they? Anyway, recertification is required to prevent discussions like that. Regarding your other point, ‘Past use’ is not valid evidence of trustworthyness either. And I don’t know anything about XTS usage. But I am not aware of a case where TSOL is used as MLS; Radiant Mercury (on TSOL) filters stuff but no unequal security levels I know of, but then I have heard stories... On your CAPP comment, I’m no CAPP guru but I’ve read it and I can’t think of anything CAPP said or could (reasonably) say that would negate MLS. That implication can’t be substantiated should be cleaned out. I tried to fix that but I guess I failed. Any help with that would be nice.

Regarding your point about containing MLS functionality, again, certification to LSPP certifies that it has label functions, but they depend on the kernel for protection from subversion and corruption, which it doesn't provide. I am not sure how to prove this without an involved discussion on secure operating systems. Maybe someone will help. Corruptable lables are not usable for protecting US National security levels.

I am a sure concerned about leaving any implication that those products can be used for MLS because there is such a dangerous tendency today to grab anything with the slightest hint of MLS and run MLS with it. I hear the claim “After all, its EAL-4, which is good enough, and anyway it is the best we have!” In the previous decades there was enough MLS research funding to maintain a functional level of MLS expertise, and the Yellow Book nailed down mapping of MLS environments to OS requirements. With that all gone interpretation of CC two dimensional certifications (EAL & PP) is technically overwhelming even for those with the expertise to do it.

John 06:26, 31 October 2006 (UTC)