Talk:Multilevel security

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

MLS isn't a model[edit]

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.[reply]

John 17:38, 30 October 2006 (UTC)[reply]

Definition of MILS and MLS[edit]

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)[reply]

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)[reply]

Requested move[edit]

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)[reply]

  • Oppose. – AxSkov (T) 07:15, 14 July 2005 (UTC)[reply]
  • 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)[reply]

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)[reply]

  • 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)[reply]

Vendors are misleading readers[edit]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]


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)[reply]

NPOV dispute - Trusted Operating Systems[edit]

Saying :

"Vendor certification strategies can be misleading to laymen (and even some certifiers!). A common strategy exploits the layman's overemphasis of EAL level with over-certification..."

...means that vendors tend to voluntarily "exploit" CC certifications to mislead the world and to invent un-exsting functionnalities to their products. It is a wrong, free and non-neutral assertion. This have to be edited.

As well, saying that eventual limitations in CC profiles means that certified products cannot have more functionnalities than those limitations is wrong. This have to be edited as well.

Especially, about Solaris 10 Trusted extensions :

Saying :

"Because these extensions are hosted by an operating system with CAPP functionality, which assumes users will voluntarily comply with security access controls,mandatory access control is beyond the capability of Solaris..."

...is wrong as MAC principles are within Solaris kernel but not activated by default. In the default context, being CAPP compliant does absolutely not means those principles do not exists and cannot be activated in Solaris. What CAPP compliance means, is that those MAC principles and functionalities are not used in the perimeter of a CAPP focused default Solaris TOE.

What does TX is activating those principles and Solaris kernel related features, so that Solaris 'TX' do not use DAC stuff by default anymore, but real labeled and multi level implementation of MAC principles for any entity on the system, at the kernel level. The trusted extensions are not a "plugin", "module", or other stuff of this kind. It is simply the default Solaris 10 MAC features activation.

By MAC principles, I mean at least what is defined on the associated wikipedia page. When I say they are implemented in Solaris, I do not say "... just trust me". Those are facts that can be checked from Trusted Extension documentation, kernel sources and headers and experimentation.

As well, in no way users have to "voluntarily comply" to security policies for those policies to be applied, nor on default Solaris, neither on Solaris with Trusted Extensions activated.

Saying :

the labels and roles cannot be enforced on users without their voluntary cooperation

... is totally wrong both on Solaris 10 TX (for labels and roles) and on default Solaris (for roles, labels being not activated by default). Labels are implemented at kernel level, out of reach of user-space, and their internal handing complies Bell and Lapadula as well as Biba principles (in other things). Those are facts that can be checked from Trusted Extension documentation, kernel sources and headers and experimentation.


Saying :

The security target includes both desktop and network functionality which do not warrant MLS capability

... is non neutral.

TX desktop is a multilevel desktop. It cannot be said what is quoted. Saying that including a desktop in the ST do not "warrant" MLS capability sneakly implies that multi level TX desktop is not MLS grade, thing it have been designed to be from the origin.

As well with the networking : TX includes MLS Trusted Networking and CIPSO protocol. So same notice than before : saying that because of being in the ST, the multi-level networking features of TX do not warrant MLS capability of TX sneakly means TX cannot be MLS. In any way, both of those points sounds to me very far from being neutral as well.

Another time, I do not say "... trust me". Those are facts that can be checked from Trusted Extension documentation, kernel sources and headers and experimentation.

This article violates wikipedia neutrality policy, using partial assertions (...vendors only want to mislead you... etc...), and wrong technical and functionnal assertions (S10 wrong facts) to harm a technology. This cannot be left as is.

I first tried to discuss privately with the author on his discussion page.

As this does not worked and it starts now looping around the "vendors mislead you... certification have limits, so certified systems cannot be XYZ-able,etc..." thing, I have no other choice than flaging this article as non neutral so to broaden the discussion before suggesting a content.

I do not want to generate an edit war, but this section is non-neutral as well as technically and functionnaly wrong so it have to be edited. Things have to be clear : I am not searching for "commercial" abuse of wikipedia, I just cannot let such wrong content in place about Solaris 10 Trusted Extensions.

Solaris 10 Trusted Extensions is a MLS system.

Discussion is now opened...

Bruno. Bjgiza (talk) 07:24, 13 December 2008 (UTC)[reply]

CLOSING THE DISPUTE :
As no comments were done but the wrong facts cited were edited, I removed the non neutrality flag and close the discussion.
Bruno. Bjgiza (talk) 14:20, 15 December 2008 (UTC)[reply]


personal style is background information[edit]

The author(s) sound like being all-in on that topic and it is hard to transfer information down to one's own level. With that said: This is one of the most rewarding to read articles i've found on wikipedia. I actually learned something, and was able to take away many background infos I had *never* been aware of. That's as someone who went through the NSA C2 guides back in windows NT times just for fun, and read enough documentation to already know about trusted systems before wikipedia was even a thing. That means, knowing the concepts, but not working in that specific domain, this article was GREAT.

So, please, deleters and editors of "opionated articles", at least take note: This article is not how it should be in an encyclopedia. But, the level of knowledge to be gained from this one is INSANE. Please don't dumb it down till it's useless to people who can actually learn from it. don't ruin it. What I think is needed is a dozen articles around this one building the knowledge body to read _THIS ONE_.

2001:A60:162D:2101:7A24:AFFF:FE42:3EA5 (talk) 20:20, 26 March 2015 (UTC)[reply]

unresolved reference[edit]

There is an unresolved reference where it says "more below" about an OS certified 6+ - but nowhere below is a 6+ certification mentioned again. — Preceding unsigned comment added by 62.214.54.250 (talk) 08:44, 19 October 2017 (UTC)[reply]

External links modified (February 2018)[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Multilevel security. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:29, 8 February 2018 (UTC)[reply]

Bitching and railing[edit]

MSL does not mean multiple single level: it means multiple security level.

The definition of MSL as some unholy union of system-high enclaves demonstrates frank misunderstanding of the term "system-high."

The notion that MLS can be understood either as a processing mode or as a capability--combined with frequent railing against overloaded terms--belies the author's total ignorance of the term "capability," which is itself overloaded and applies in capability-based systems.

This is but one of many, many reasons why Wikipedia is beneath contempt. Any imbecile can destroy valid work and interpose trash, and--if he has enough sixteen-year-old "administrator" buddies--what he says, goes.

Every last one of you should be tortured to death _extremely_ slowly.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Multilevel_security&oldid=1202211146"