18

Someone can suggest me a real situation in which is better to use MAC (Mandatory Access Control) instead of DAC (Discretionary Access Control) or RBAC (Role Based Access Control)? And in which DAC is better than the others? And in which RBAC is the best?

I know the theoretical notions, and I know that RBAC is better in situation in which we want to assign the rights not to the people, but to the specific job. I know also that MAC and RBAC is better in situation where we want to avoid that an user can manage the rights.

Liviu
  • 103
  • 2
mcfan
  • 643
  • 2
  • 6
  • 7
  • 1
    Welcome to [security.se]! This is related but not a duplicate, might have interest for you: http://security.stackexchange.com/a/348/33 – AviD Jul 20 '14 at 11:01
  • Thank you! I have already seen this, but I didn't find and answer to my question. – mcfan Jul 20 '14 at 11:04
  • Your question is quite vague and you shouldn't expect one final and objective answer to it. The answer very often is "it depends". If you have a more specific thing in mind, why not edit your question? – Steve Dodier-Lazaro Jul 20 '14 at 12:40
  • I'm looking for a practical examples, a real case. – mcfan Jul 20 '14 at 13:25

2 Answers2

15

DAC is the way to go to let people manage the content they own. It might sound obvious, but for instance DAC is very good to let users of an online social network choose who accesses their data. It allows people to revoke or forward privileges easily and immediately. Reactive access control, Seeing further and Laissez-faire file sharing provide nice examples of research on DAC with users.

RBAC is a form of access control which as you said is suitable to separate responsibilities in a system where multiple roles are fulfilled. This is obviously true in corporations (often along with compartmentalization e.g. Brewer and Nash or MCS) but can also be used on a single user operating system to implement the principle of least privilege. RBAC is designed for separation of duties by letting users select the roles they need for a specific task. The key question is whether you use roles to represent tasks performed on your system and assign roles in a central authority (in which case RBAC is a form of MAC); or if you use roles to let users control permissions on their own objects (leading to multiple roles per object and absolutely no semantics in roles, even though it's theoretically possible).

MAC in itself is vague, there are many many ways to implement it for many systems. In practice, you'll often use a combination of different paradigms. For instance, a UNIX system mostly uses DAC but the root account bypasses DAC privileges. In a corporation, beyond separating your different departments and teams with MAC/RBAC you may allow some DAC for coworkers to share information on your corporate file system.

It'd be better to make your question specific and tell what system(s) you want to protect, if any. What access control to use always depends on the specific situation and context you're considering.

Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • Don't you mean "RBAC is a form of DAC"? – Michael May 19 '15 at 07:25
  • Nope. RBAC technically isn't MAC, though in practice I've only seen it as a form of MAC, because centrally managing roles is much easier and allows you to assign clear semantics to roles. See http://www.profsandhu.com/confrnc/rbac/r98dac%28org%29.pdf if you *really* want to do DAC with RBAC but it's not because something is possible that it is a good idea. Of course if you feel the answer is not rigorous enough (it isn't!), I can extend it. – Steve Dodier-Lazaro May 19 '15 at 07:55
  • No, it is not MAC, but isn't RBAC related to DAC? In this paper (http://w3.cs.jmu.edu/kirkpams/papers/inetsec09-cdac.pdf) the auther mentions: "RBAC is similar to DAC, except that the notion of identity is replaced with a role." I like that explanation, do you think it is wrong? – Michael May 19 '15 at 07:59
  • 1
    I think it's a poor shortcut being taken. In DAC/MAC, permissions are given to user identities, whilst in RBAC, permissions are given to roles; a separate policy element assigns possible roles to users (especially when doing MAC with RBAC); and users select roles they want to use for each computing session. – Steve Dodier-Lazaro May 19 '15 at 08:02
  • Also I usually cringe at "Context-dependent " because it's usually extremely superficial models. I have planned to write about the relationship between contextuality (http://www.dourish.com/publications/2004/PUC2004-context.pdf) and access control mechanisms, but have had no time to put things down formally... We can take that conversation off (via email) if you want. – Steve Dodier-Lazaro May 19 '15 at 08:07
  • Yes, I agree indeed that it is a poor shortcut after reading your explanation. Context-dependent is very interesting though, although I often call it Attribute-based access control, just like in this (short) paper: http://csrc.nist.gov/groups/SNS/rbac/documents/kuhn-coyne-weil-10.pdf . I don't think it is superficial, but that's maybe a discussion that is going too far to put in comments. – Michael May 19 '15 at 08:10
  • By the way, context-dependent access control is indeed poorly explained in Kirkpatrick's paper. I only referenced it for his comparison of RBAC to DAC. – Michael May 19 '15 at 08:19
  • ABAC is something different from the stream of papers that discusses using positivist context representations for security decision making. This 'context' could maybe be formalised as attributes but there are multiple forms of successful context free attribute-based ACs out there, e.g. id cards for buying alcohol! – Steve Dodier-Lazaro May 19 '15 at 09:17
4

Each system is used for a different overriding security requirement. The three main security requirements are confidentiality, integrity, and availability.

MAC supports a security requirement of confidentiality more so than the others. DAC supports the security requirement of availability more so than the others. RBAC supports the security requirement of integrity more so than the others. there is another...

MAC makes decisions based upon labeling and then permissions. DAC makes decisions based upon permissions only. RBAC makes decisions based upon function/roles.

When the system or implementation makes decisions (if it is programmed correctly) it will enforce the security requirements. If you use the wrong system you can kludge it to do what you want. This happens quite often.

They are not mutually exclusive except for DAC vs MAC. There are combination implementations DAC/RBAC the best example of this Active directory roles and permissions.

RBAC - tends toward databases - a classic example of where you cannot use one of the other systems and must used RBAC is for customer service and billing. When you call the cable company to get your pay-per-view the Customer service representative will say I'm sorry let me transfer you to Billing so that you can pay your overdue bill- they know you have an overdue bill but their role prevents them from taking your credit card information directly. When you get transferred to billing you pay your bill and say can I have my service. They say let me transfer you back- I see you want this service but that's not my function. So both roles can see all the data (no confidentiality) but can only manipulate the fields that they have a particular set of responsibilities for (integrity). -you can argue DAC: but fits the "more so" rule.

MAC - tends toward a military systems or very narrowly defined, high security requirement implementations. 2 that are used quite often TRusted-Solaris and LINUX- MAC kernel module (this used to be SELinux) there're others but you don't care. One of the key elements that only appears in MAC is a construct of dominance. If you have secret level clearance, no amount of permissions is going to get you to see a Top secret document. In commercial entities it is rare that you need this construct. But it brings up the second point that is unique to MAC- if an activity is not specifically allowed then you cannot do it. (this breaks lot of commercial uses primarily because of rapid change to The mission or system requirements) An excellent use of MAC would be on a Web server- where you would write a custom policy (and this is very narrowly defined to that implementation) that states the Core processes can only be executed by the System account. Any processes spawned from that would be required meet specific permissions.

DAC - everybody uses it and the person before me answer well enough.

D0c0z
  • 61
  • 2