Jump to content

Talk:Bell–LaPadula model

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

This is an old revision of this page, as edited by Dthvt (talk | contribs) at 22:42, 27 June 2007 (Merge High watermark: Removing proposal to merge w/ BLP). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Cleanup Request August '06

I put in the 'cleanup request for the following reasons:

  1. The article doesn't distinguish between the abstract mathematical model and the implementation. The article probably needs separate sections to talk about them.
  2. The "See Also" section points to some other models, but the article may need some discussion of how the other models are related.
  3. Having a section on "Strong * Property" suggests that the article should talk more specifically about BLP extensions of all kinds. I think the only reason Strong * Property is in there is because some deluded person in the CISSP training world included it in study materials, despite its relative unimportance. But we can't talk about extensions unless we distinguish between those that extend the theoretical model (System Z for example) and those that seem more implementation related (Strong * Property).

If the cleanup doesn't happen otherwise I might get to it in a month or two. Cryptosmith (Rick Smith) 15:50, 14 August 2006 (UTC)[reply]

This article desperately needs a section on criticisms of the Bell-LaPadula model. One of the most serious criticisms is that the *-property, by requiring "high" processes to only communicate with other "high" processes, forces many processes by to labelled higher than they would otherwise need to be, and that this works directly against the Principle of Least Authority. Other criticisms of BLP and skepticism about its real-world relevance are discussed in these threads:
http://www.eros-os.org/pipermail/cap-talk/2005-December/004597.html
http://www.eros-os.org/pipermail/cap-talk/2006-January/004712.html
http://www.eros-os.org/pipermail/cap-talk/2006-July/005501.html
--DavidHopwood 15:17, 31 December 2006 (UTC)[reply]

--Mattpalmer1086 13:53, 2 March 2007 (UTC) Matt Palmer: I second that this article be cleaned up... can I suggest whoever does so actually reads the original paper by Bell and LaPadula? Especially on the topic of the *-property, which is stated in the original as "in any state, a current access (subject, object, attribute) implies: level(object) dominates current-level (subject) if attribute is a; level (object) equals current-level (subject) if attribute is w; and level (object) is dominated by current-level (object) if attribute is r." The * property does NOT prevent high level subjects from writing to low level objects. It merely prevents an access state existing that would allow downwards information flow. A high level subject, if he doesn't hold any observe access at a high level, is free to operate at a lower level, and write to a low level object. It's all in the original - this extra stuff seems to be a bit like chinese whispers (even the way I was taught it was actually wrong by the terms of the original paper that * property implies level(object) >= level(subject).). It doesn't - it just says no alter access can be granted lower than current observe access, and no observe access higher than current alter access. This implies that a subject can only write at a single leve, as the write operation in BLP implies both observe and alter. The single level requirements follows from the * property - a write at two levels would involve an observe access dominating an alter access - which is prohibited.[reply]

I may have a go at rewriting myself if I get time. By the way, the links to the capability section is interesting (eros), but they aren't the best people to criticise MLS approaches. Personally, I love capabilities and the E language stuff - but it's a million miles away from MLS. Finally, the article as it stands does not do justice to security levels - some more examples would be nice.

Features section

The article is not mentioning the property called the Strong * Property value. According to this property, the subject can only read/write at the same security level (clearance and classification must be equal). In some resources, this property is cited instead of the The Discretionary Security Property.

Please refer to:

Chapter 5 - Security Models and Architecture

CISSP: All-in-One Exam Guide, Third Edition by Shon Harris McGraw-Hill/Osborne © 2005

--Rygar81 22:08, 6 August 2006 (UTC)[reply]

  • This appears to be a bogus term, even if it shows up in a CISSP Study Guide (yes, even such writers are human). A Google search uncovered two references - one to that Study Guide itself, and one to Rob Slade (he reviews a lot of security books) who argues that the term is bogus. I've seen systems implement such a property, but it's usually because the system has no way of allowing write only access to objects, so they need to make the shortcoming sound like a feature. Certainly it is not part of the classic BLP model. I know of no formal mathematical arguments that rely on defining a strong * property (anyone else know of one?). If Rygar81 would like to include a description in the BLP entry, go ahead, but be sure to cite the source (which I don't have) and note that the term is not widely used. Rick Smith 18:41, 7 August 2006 (UTC) (PhD, CISSP, ISSAP, ISSEP).[reply]
  • I did a bit more poking around with Google (search: bell la padula "strong * property") and I can't find any primary references that use the term. I can find two sources: CISSP Exam Prep Guides of various sorts, a book Secured Computing published in '02 by one Carl Endorf, and reviews by Rob Slade of said books (including a suggestion that Endorf's book is essentially a prep guide, too). The definition is, as I said above, somewhat plausible, but I suspect it's a marketing term introduced by a vendor rather than a serious term used in the industry. I've been dealing with mulitlevel models and technology for a long time, and I can say that I've never used it myself. Rick Smith 19:21, 7 August 2006 (UTC)[reply]
  • OK, I've found a link that appears to be to a relevant chapter of the 2nd edition of the Shon Harris book. On page 213 Harris illustrates a total lack of understanding of the BLP model, by claiming that it consists of 3 parts: the Simple Security Property, the * Property, and the Srong * Property, with the latter defined as above (write to current level only!!!). In fact, you only need one of those * properties, not both. So Harris is not a reliable source and should not be used as a reference for defining the Strong * Property, assuming it really exists. Rick Smith 19:21, 7 August 2006 (UTC)[reply]
  • Hi Rick, I have also made some researches.

From:

Chapter 5 - Security Architecture and Models The CISSP Prep Guide: Mastering the CISSP and ISSEP Exams, Second Edition by Ronald L. Krutz and Russell Dean Vines John Wiley & Sons © 2004

"In some instances, a property called the Strong * Property is cited. This property states that reading or writing is permitted at a particular level of sensitivity but not to either higher or lower levels of sensitivity."

This is another source which talks about this property. I infer it is not a bogus term. I agree with you that Shon Harris book is confusing about BLP model. However this term seems to exist. Rygar81 00:20, 11 August 2006 (UTC)[reply]

  • Let me say that Shon Harris is not confusing so much as she is wrong. I haven't been able to find the term anywhere except in CISSP study guides. I find that very suspicious, but I will go ahead and add something about it, based on my research on the subject. Cryptosmith (Rick Smith) 20:15, 12 August 2006 (UTC)[reply]

Success! I found a reference to a paper by Ravi Sandhu that defines the Strong * Property. The article will be edited accordingly. Cryptosmith (Rick Smith) 21:27, 12 August 2006 (UTC)[reply]

That's great! I completely agree with your last change about Strong * Property. Rygar81 21:29, 13 August 2006 (UTC)[reply]

--Mattpalmer1086 13:23, 2 March 2007 (UTC) The Strong *-Property is a complete red-herring. It's not used by anyone who does work on MLS models as far as I'm aware (and I've built database systems based on BLP). The paper by Ravi Sandhu states that "It is motivated by integrity considerations. The (weak) star-property allows a U user to write S-data. This can result in overwriting...". This is just not true by the terms of BLP, but may be true in other mandatory models. In BLP, a U user can never write to S data - they can only append - which is an alter without an observe. So no data can be overwritten. He is talking specifically in the context of database systems that are mandatory and multi-level secure. Although a better reference for MLS databases is the work on SeaView by Dorothy Denning. Anyway, at best it's an almost unheard of security property that no-one in the industry uses. It would be far better to spend time getting the actual *-property right. We must make the general distinction between mandatory multi-level secure systems in general - whether database oriented or not - and the specific BLP model.[reply]

Merge High watermark

High watermark was introduced in Clark Weissman's Security controls in the ADEPT-50 timesharing system that appeared in the AFIPS Conference Proceedings, volume 35, pages 119--133. FJCC, 1969. As such it preceded the Bell-La Padula work. Volume 1 appeared in 1972. It is not appropriate to include as part of the BLP. David Bell 21:31, 18 December 2006 (UTC)[reply]

Proposing that High watermark be merged into Bell-LaPadula model as it is an extension of that model & the current article is very short. Dthvt 04:45, 9 December 2006 (UTC)[reply]

--Mattpalmer1086 13:30, 2 March 2007 (UTC) But it has nothing specifically to do with the actual BLP model! It's related by the more general concept of multi-level secure systems, but BLP doesn't work like this. A link would be OK, but it has no direct relevance.[reply]

Well, I don't see any reason to leave the merge tag on this page, so removing it... Dthvt 22:42, 27 June 2007 (UTC)[reply]