From http://msdn.microsoft.com/en-us/library/jj709705.aspx

In contrast to the DAC model, which is oriented around objects, the AzMan RBAC model attempts to orient the common administrative experience around user roles. Rather than assigning permissions to objects, an AzMan RBAC framework enables applications to present administrators with a management experience more aligned with the organizational structure of a company. AzMan RBAC provides a central object—a role—that a user is assigned to perform a particular job or application function. Ideally, an RBAC application is designed such that the administrator requires less knowledge of the object storage structure. This approach can be used if the RBAC application provides a simplifying abstraction into resource collections referred to as scopes.

Can someone please explain to me how this is any different at all from user/group ACLs?


Say I want managers to have read access to /mnt/network_performance_reports, sysadmins to have full read/write access, and everyone else to have no access.

I would think that (on Linux with POSIX ACLs, I don't really know Windows) I could

  • set a default ACL on /mnt so everything under it is effectively chmod 0700 (directories) or 0600 (files).
  • create a sysadmins group and set up a read/write default ACL for sysadmins
  • create a managers group and set up a read-only default ACL for managers

That's not exactly easy to manage (not centralized, blech!) but it does the same thing, doesn't it? I don't think I'm quite understanding the concept.

When people talk about RBAC in operating systems, are they effectively talking about a layer of abstraction on top of MAC/DAC systems to make management of those easier for large organizations? Or are they talking about something that is different internally; i.e. is associated with completely different methods and data structures in the the OS kernel?


5 Answers 5


First, I think we should clarify vocabulary. DAC means discretionary access control, which means someone (to be defined) can decide who accesses what within the system, when MAC, mandatory access control, tends to relate to systems where access cannot be given within the system. In my understanding, neither DAC nor MAC implies a specific implementation.

Concerning RBAC in the UNIX world, IBM has a good explanation on why this is important: http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.security/rbac.htm?lang=en. The AIX RBAC implementation implements a partition of the set of all root accesses and allows specific roles to have specific admin access (on the network, on the passwords, and so on)

Your example with sysadmins and managers is a good one although limited to the user space and file access.

So regarding your last question about the place of an RBAC UNIX implementation (layer or different internals), it seems it largely depends on what access we're talking about.

  • If file access is concerned, RBAC can be implemented with existing functions, although ressources a role can access are not centrally managed as you mentioned. A layer of abstraction could deal with that.
  • if root accesses are to be divided in many accesses (The AIX RBAC implementation), then I guess some internal work is needed with new methods and data structures in the OS kernel.

Hope this helps, Regards,


Answered per the comments by @woliveirajr above. Theoretically there is no difference between "minimal" RBAC as implemented in filesystem permissions, and ACLs applying permissions only to groups. So I'm going to guess that the Windows implementation is a layer of abstraction on Windows ACLs, rather than a separate permissions system using its own driver or such.


You should check out the authoritative source for RBAC, namely NIST. They have an entire website dedicated to RBAC.


After doing a little research on your question, I have read that both MAC and DAC can be implemented with RBAC.

Obviously there is a clear connection between RBAC and DAC when it comes to simply maintaining ACLs. RBAC seems to be just a higher level, less granular style of organization. RBAC is more appropriate for handling things like separation of duties concerns in addition to controlling access to data objects.


RBAC utilizes a set of policies and rulesets to limit the actions of multiple users, including root, so essentially, it makes local root exploits to gain root useless. Grsecurity's RBAC is my favorite, it limits the output of dmesg() and netstat() so the attacker cannot find any useful information for attacking the system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .