Talk:Mandatory access control

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

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

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

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

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

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

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