Talk:Mandatory access control

From Wikipedia, the free encyclopedia

Contents 1 Rewrote introduction 2 Neutrality of "MAC implies robustness" disputed 3 Untitled comment 4 Help! 5 Change the focus of the article

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

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

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

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

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