RSBAC

RSBAC is an open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a).

Features
  • Free open source GNU General Public License (GPL) Linux kernel security extension
  • Independent of governments and big companies
  • Several well-known and new security models, e.g. mandatory access control (MAC), access control list (ACL), and role compatibility (RC)
  • On-access virus scanning with Dazuko interface
  • Detailed control over individual user and program network accesses
  • Fully access controlled kernel level user management
  • Any combination of security models possible
  • Easily extensible: write your own model for runtime registration
  • Support for latest kernels
  • Stable for production use
  • Easily portable to other operating systems

The RSBAC system architecture has been derived and extended from the Generalized Framework for Access Control (GFAC) by Marshall Abrams and Leonard La Padula.

RSBAC means "ruleset based access control" and is also a role-based access control (RBAC) solution. The two acronyms can cause confusion.

In his essay "Rule Set Modeling of a Trusted Computer System", Leonard LaPadula describes how the Generalized Framework for Access Control (GFAC) approach could be implemented in the UNIX System V operating system. He introduced the clear separation between Access Enforcement Facility (AEF), Access Decision Facility (ADF) with Access Control Rules (ACR), and Access Control Information (ACI).

The AEF as part of the system call function calls the ADF, which uses ACI and the rules to return a decision and a set of new ACI attribute values. The decision is then enforced by the AEF, which also sets the new attribute values and, in case of allowed access, provides object access to the subject.

This structure requires all security relevant system calls to be extended by AEF interception, and it needs a well-defined interface between AEF and ADF. For better modeling, a set of request types was used in which all system call functionalities were to be expressed. The general structure of the GFAC has also been included in the ISO standard 10181-3 Security frameworks for open systems: Access control framework and into The Open Group standard Authorization (AZN) API.

The first RSBAC prototype followed La Padula's suggestions and implemented some access control policies briefly described there, namely mandatory access control (MAC), functional control (FC) and Security Information Modification (SIM), as well as the Privacy Model by Simone Fischer-Hübner.

Many aspects of the system have changed a lot since then, e.g. the current framework supports more object types, includes generic list management and network access control, contains several additional security models, and supports runtime registration of decision modules and system calls for their administration.

RSBAC and other solutions

RSBAC is very close to Security-Enhanced Linux (SELinux), as they share a lot more in their design than other access controls such as AppArmor.

However, RSBAC brings its own hooking code instead of relying on the Linux Security Module (LSM). Due to this, RSBAC is technically a replacement for LSM itself, and implement modules that are similar to SELinux, but with additional functionality.

The RSBAC framework incorporates complete object status and has a full knowledge of the kernel state when making decisions, making it more flexible and reliable. However, this comes at the cost of slightly higher overhead in the framework itself. Although SELinux- and RSBAC-enabled systems have similar impact on performance, LSM impact alone is negligible compared to the RSBAC framework alone.

For this reason, LSM has been selected as default and unique security-hooking mechanism in the Linux kernel, RSBAC coming as a separate patch only.

History

RSBAC was the first Linux role-based access control (RBAC) and mandatory access control (MAC) patch.

gollark: If you want to declare a type with equality and hashing and other such apioforms, you'll need an entire file of rather a lot of apiocode.
gollark: It's quite verbose and annoying.
gollark: You could try Clojure or Scala or Kotlin or Apioforms or something.
gollark: If you're not using Java's OOP features (they're bad because OOP, so good choice) why even use Java?
gollark: Okay.

See also
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.