Talk:Mandatory access control

Untitled comment

Made the introduction clearer and more relavant.

The claim that MAC has a goal of defining an architecture was not made clear. This needs to come out.

The references to FLASK and Generalized Framework for Access Control (GFAC) architectures seem to pursue an agenda that lacks relavance. This needs to come out.

Comments? John 18:31, 27 October 2006 (UTC)

Help!

This article is gibberish to someone, unless they already know what MAC is! KeithCu 00:36, 6 July 2007 (UTC) if you know this ,but this article help me.

Gibberish is not good. Can you clarify what parts were unclear? More specific comments would be helpful. John 20:02, 23 July 2007 (UTC)

KeithCu, are you referring to the material that was added just after 2006-10-24? I do find that text fairly bureaucratic, and it seems to assume a lot of prior context. Ka-Ping Yee 10:45, 26 July 2007 (UTC)

Tried to add some prior context regarding the 'hidden' implication of high robustness underlying the term MAC. Is that better or worse? John 05:42, 11 September 2007 (UTC)

Much worse -- see above. --DavidHopwood (talk) 21:19, 19 January 2008 (UTC)

Change the focus of the article

When you read this article, you get the impression that MAC is all about security classification rules (secret, top secret, etc.) and multi-level secure processing of classified information. MAC is actually much more general, and I think this association is outdated and needs to be de-emphasized. The Trusted Computer System Evaluation Criteria (TCSEC) does discuss MAC in this context, but that was in 1985. The NSA's whitepaper (Loscocco et al, which is the last of the references), which at 1998 isn't exactly recent either, states that the TCSEC's definition is too narrow and "is insufficient to meet the needs of either the Department of Defense or private industry." I think the NSA is right, and it's even more true now than it was in 1998.

Access control is really about constraining the ability of a "subject" (which really means a process or thread) to perform some sort of operation on an "object" (such as a file, TCP/UDP port, shared memory segment, etc.) based on attributes of the object and the subject. An authorization rule examines the relevant attributes of the subject and object and decides whether the operation can proceed. So any operation by any subject on any object will be tested against the set of authorization rules (the "policy") to determine if the operation is allowed. So while this kind of architecture can be used to ensure that a "secret" process cannot access a file with a "top secret" attribute, it can also be used to ensure (for example) that a web browser can only access http ports, or create files only in certain directories. I think the latter sort of usage is ultimately more important than the former.

The "mandatory" part of MAC is due to the fact that the policy is centrally controlled by a security policy administrator; users don't have the ability to override the policy and (for example) grant access to files that would otherwise be restricted. By contrast, discretionary access control leaves policy decisions (at least partially) in the hands of the users. The advantage of MAC over DAC is that it allows you to set up security rules that users can't break, either intentionally or accidentally. This is useful for more than just MLS. It is also useful for security administrators to protect systems from various forms of malicious software, which is a much bigger issue that seems to keep increasing.

In addition to changing the focus of the article, I would also get rid of the entire "MAC Precludes Informal Access Decisions" section. This section seems to confuse computer security policy (MAC) with human security policy (security clearances). They are not the same. Humans can still informally or casually make access rules or decisions, regardless of MAC. And computer security policy is always formally implemented, whether it's MAC or DAC or anything else. Of course, whether or not the formal implementation is any good is a different matter.... But the point here is not to confuse policies that apply to humans with those that apply to a computer.

My main argument, however, remains that the focus of the article should be changed so that MAC is not treated as nearly synonymous with MLS.

Gdlong (talk) 16:24, 2 January 2008 (UTC)

I think technically this idea is right. There is a substantial segment of the field that uses the term MAC to imply a level of robustness (or "High Assurance") for access controls. It would be nice to somehow acknowledge this 'unofficial' connotation, for readers that would hear the term in that context and look it up here. John (talk) 21:35, 2 January 2008 (UTC)

I think that the article misses the point about the difference between "mandatory" and "discretionary", but prior comments are not quite there yet, either. The idea is that mandatory access controls are controls that cannot be bypassed, either by users or by applications. Classic Orange-Book MLS systems associated a label with subjects to ensure that applications were contrained to enforce labels on the information they manipulated.

-- Andrew Myers, 15 January 2008 —Preceding unsigned comment added by 128.84.96.80 (talk) 15:48, 16 January 2008 (UTC)

Andrew, I am not sure we can characterize the essence of MAC with the 'cannot be bypassed' notion. Does that imply that only flawless systems are MAC? Are there any? At the other extreme is Windows, with access controls, but they are easily bypassed. Should DAC be bypassable by those not authorized? It seems to me MAC means something beyond bypassability, something about the kind of rules, or the kind of enforcement that is not subject to the digression or judgement of users. I think it once had a very clear meaning, but now we are trying to make it apply to the less rigorous 2000s.

John (talk) 06:17, 17 January 2008 (UTC)

I agree about the article missing the point about difference between mandatory and discretionary access, but I disagree about prior comments not being there either. Rather than using my own words, I'll quote from the NSA paper (Loscocco et al) referenced in the article: This paper instead uses the more general notion of mandatory security defined in [59], in which a mandatory security policy is considered to be any security policy where the definition of the policy logic and the assignment of security attributes is tightly controlled by a system security policy administrator....Likewise, as defined in [59], this paper uses a more general notion of discretionary security in which a discretionary security policy is considered to be any security policy where ordinary users may be involved in the definition of the policy functions and/or the assignment of security attributes. Here discretionary security is not synonymous with identity based access control; IBAC, like any other security policy, may be either mandatory or discretionary[58]. I think this is a good, useful definition of MAC vs DAC that seems to have a bit of traction.

In principle, neither MAC nor DAC controls can be bypassed. However, with DAC, the idea of "bypassing" doesn't make as much sense, since security policy (such as access control rules) are at least to some degree defined and managed by users. This business about associating a label is simply a mechanism by which a subject (which I would call a process rather than an application) is constrained in its ability to access an object. More generally, you have security attributes associated with the subject, and security attributes associated with the object (which may be a different set of attributes than those associated with the subject), and security policy rules which govern the subject's ability to access to the object based on both sets of security attributes. This is true for both MAC and DAC. The only difference between MAC and DAC is in who sets the policy. This is in principle, of course; in practice, MAC and DAC implementations are different and don't often have much in common.

If no one objects, I can rewrite at least the first part of the article along these lines. - Gordon (Gdlong (talk) 22:33, 23 January 2008 (UTC))

-- Random reader, 27 October 2008 When re-editing, can we have it in english please? "are sometimes making" and similar is just jarring... —Preceding unsigned comment added by 211.29.157.177 (talk) 00:20, 27 October 2008 (UTC)

Neutrality of "MAC implies robustness" disputed

The term 'mandatory' used with access controls has historically implied a very high degree of robustness that assures that the control mechanisms resist subversion, thereby enabling them to enforce an access control policy that is mandated by some regulation that must be absolutely enforced, such as the Executive Order 12958 for US classified information.

This is wrong. If a system includes security mechanisms that attempt to restrict changes of security configuration by users other than administrators, then the system is a MAC system. If those mechanisms fail, then it is an insecure MAC system.

The practical effect of believing that robustness is part of the definition of MAC is to allow vendors or advocates of MAC systems to get a free ride: unlike any other technical categorization of security systems, MAC systems would in that case be secure by definition. This can only severely hamper objective discussion of their actual effectiveness, at both implementation and design/architecture levels.

--DavidHopwood (talk) 20:54, 19 January 2008 (UTC)

I agree with the general thesis above. Still, MAC did (in formal MLS circles, and still may) informally connote high robustness. While there is something wrong with the statement, there is some notion that should probably be retained from that statement. Would it be helpful to distinguish between MAC-appropriate-robustness and MAC-functionality?

Would there be a problem with the following statement?:

The term 'mandatory' used with access controls has historically implied an associated need for a very high degree of robustness to assure that the control mechanisms resist subversion, thereby enabling them to enforce an access control policy that is mandated by some regulation that must be absolutely enforced, such as the Executive Order 12958 for US classified information.John (talk) 20:28, 9 March 2008 (UTC)

Rewrote introduction

I completely rewrote the introduction, giving it less of an MLS flavor. I tried to focus on what MAC actually is and what it does, and how it differs from DAC. I noted the historical association with MLS, but also more recent developments.

I deleted the "MAC Precludes Informal Access Decisions" section (which I felt was just wrong -- see "Change the focus of the article" comment for the reasoning) and made a couple minor edits to other sections. However, the rest of the article is still limited to the narrow MLS focus (maybe it should be moved in its entirety to the MLS page?). For this reason, I kept the cleanup tag.

--Gdlong (talk) 19:47, 29 January 2008 (UTC)

Please move the DAC OUT of the article

DAC is a different topic and could be a link in SEE ALSO but has absolutely no business being the beginning of the article (after prologue) of MAC. — Preceding unsigned comment added by 72.219.201.25 (talk) 14:37, 17 August 2015 (UTC)

Please rewrite "thesible" "privelage" rant

The History section reads at best like brain storming and at worst like a disorganized rant, besides the many spelling mistakes. If anyone knowledgeable could maybe rewrite it? -- 89.182.155.123 (talk) 08:44, 19 August 2015 (UTC)

This is one of the worst articles I ever saw on WP

In special the recent additions are completely unrelated to the topic and just make a nice joke, see e.g.: "heated transistor tubes".... It seems to be a good idea to remove most of the current text in the article. Schily (talk) 08:45, 19 August 2015 (UTC)

@Schily: I deleted all that. Indeed, it's as if no one who cares is watching this article. The only reason I'm here is that the editor who added that nonsense showed up in another page I'm watching and I was curious as to what else it had done. No doubt I'll get some blowback... Jeh (talk) 06:59, 19 September 2015 (UTC)

@Jeh: Thank you for mentioning that idea! I sometimes check for other edits by the same person, but in this case I did not. Schily (talk) 09:15, 6 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Mandatory access control. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20070715134110/http://csrc.nist.gov:80/secpubs/rainbow/std004.txt to http://csrc.nist.gov/secpubs/rainbow/std004.txt

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• 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. —^{cyberbot II}_{Talk to my owner:Online} 02:35, 9 September 2015 (UTC)

Missing some key context, background, and definition

This article was never that great, but it's become worse due to some edits over the past couple years. First, while the introduction section talks about what access control is (in the context of MAC), it says nothing about the mandatory part. Second, MAC has long been associated with MLS. If you look at the history of this article, you'll see that it was uniquely about MLS for a long time, and still retains that flavor. That is a really important piece of contextual information, and anyone who is interested in MAC should know that from the very beginning. Third, much of the MLS-related information is redundant and not coherent, especially in the subsequent sections.

@Jeh: I tried to fix many of these issues by bringing back and condensing some of the information that used to be there, but you reverted the edits. Not sure why - did you read them? If not, I'll go through them one-by-one:

• Added a paragraph in the introduction to discuss the mandatory nature of mandatory access control. My reasoning is, as I said before, it's called mandatory access control, and there should be some description of what the "mandatory" part means. Also, I understand what someone previously said about this not being an article about DAC, but it's much easier to understand the mandatory nature by contrasting it with discretionary, which is the other form of access control. (And by the way, something very similar to that paragraph used to be in the introduction - someone moved it to a different section in such a way that it worsened the article IMO.)
• Added another paragraph in the introduction to provide the context of MAC - saying that it was historically associated with MLS, but that association has become weaker as MAC mechanisms are being deployed in mainstream OS's. This is key information if you want to understand anything about MAC. Again, that information used to be in there, but bit-by-bit it got removed over the years.
• Cleaned up the section titled 'Implications of the term mandatory', which applies only to MAC in the MLS context.

1. Retitled it from "Implications of the term mandatory" to "Historical Background and Implications for Multi-level Security", and brought back a paragraph that gave some historical background so that the reader understands (1) that we're talking about MAC in the context of MLS, and (2) why we're doing so.
2. This section had been edited by several people and says the same thing over and over in different ways, as if one person didn't look at what was already there, or (more likely) paragraphs were moved into that section without trying to merge them with what was already there. So I merged that information and condensed three paragraphs into one.
3. It contained various opinions, such as "vendors claiming to enforce MAC are sometimes making claims beyond their capability". That sentence/phrase was originally added more than 10 years ago, is no longer relevant, and never had any support or evidence. I am personally familiar with MLS and attempts to implement MAC in that context, and I understand why that claim was made (it isn't entirely false, or wasn't 20 years ago), but I don't think it belongs in a wikipedia article. So I removed the parts where some original author claimed that vendors don't know what they're doing. However, that concept still remains due to the sentence "This is a tall order and sometimes assumed unrealistic by those unfamiliar with high assurance strategies, and very difficult for those who are." I don't know who wrote that, but it is correct.

• In the "Degrees of MAC system strength", section, the statement "This (that all users have clearances for all data) is not necessarily true of a MAC system" is incorrect. It is true for MLS systems by definition of MLS, but not necessarily true for MAC (which is used to create/enforce MLS). So I changed MAC to MLS. There's a lot more cleanup that can/should be done to that section, but I left it alone for now. Gdlong (talk) 18:43, 24 June 2016 (UTC)

Per WP:BRD the sequence is supposed to be "be bold; someone reverts; discuss". Not "be bold; someone reverts; you revert back; discuss". Jeh (talk) 23:40, 24 June 2016 (UTC)

@Jeh: If you don't like it, change it. But do it because the of the content, don't revert simply because "you can't slurp stuff around like that" - that's not a valid reason. I think these changes have improved the article for the reasons discussed above, but if you and/or others disagree, then by all means revert or modify some (or even all) of the changes. But if you do, I think you should offer at least some explanation of why you think the previous version was better. Gdlong (talk) 05:06, 25 June 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Mandatory access control. 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:

• Corrected formatting/usage for http://schaufler-ca.com/description_from_the_linux_source_tree
• Corrected formatting/usage for https://lwn.net/Articles/267849/
• Added archive https://web.archive.org/web/20070621155813/http://jya.com/paperF1.htm to http://www.jya.com/paperF1.htm

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: 5 June 2024).

• 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) 18:40, 31 May 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Mandatory access control. 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:

• Added archive https://web.archive.org/web/20080325024250/http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html to http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html
• Added archive https://web.archive.org/web/20060504192215/http://rentzsch.com/notes/virtualizationAsAnAntivirus to http://rentzsch.com/notes/virtualizationAsAnAntivirus

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: 5 June 2024).

• 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) 02:25, 16 December 2017 (UTC)

Labels

This article doesn't even mention labels. What am I missing? If labels are discussed in another article, there needs to be a clear link to it. If anyone came to this page looking for information about labels, they would be very disappointed. debater (talk) 23:15, 30 March 2019 (UTC)