why
=>  Releases

Current version
Git/Latestdiff: 1.5.6

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

=>  Events

No events planned

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
why [2006/03/02 10:48] – integrated the real why page kangwhy [2024/12/17 10:31] (current) – [What does flexible mean ?] Remove DAZ, PM ao
Line 1: Line 1:
 +~~NOTOC~~
 ====== What is RSBAC ====== ====== What is RSBAC ======
 +
  
 ===== Key Features ===== ===== Key Features =====
Line 6: Line 8:
   * Independent of governments and big companies   * Independent of governments and big companies
   * Several well-known and new security models, like MAC, ACL and RC   * Several well-known and new security models, like MAC, ACL and RC
-  * On-access virus scanning with the Dazuko interface 
   * Detailed control over individual user and program network accesses   * Detailed control over individual user and program network accesses
-  * Fully access controlled kernel level user management+  * Virtual User Management, in kernel and fully access controlled 
 +  * On-access virus scanning with the User Space Decision Facility (UDF) interface
   * Any combination of security models possible   * Any combination of security models possible
   * Easily extensible: write your own model for runtime registration   * Easily extensible: write your own model for runtime registration
   * Support for latest kernels and stable for production use   * Support for latest kernels and stable for production use
  
-//[[:documentation:features|See the detailled feature list]]//+//[[documentation:rsbac_handbook:introduction:features|See the detailed feature list]]//
  
 ===== Why do we need RSBAC ? ===== ===== Why do we need RSBAC ? =====
Line 19: Line 21:
 [[wp>Linux]] systems, as many others in the Unix family, have a well-known lack of access control. There is a small granularity of discretionary access rights, only dividing between read, write and execute rights for file owner, and file group members. [[wp>Linux]] systems, as many others in the Unix family, have a well-known lack of access control. There is a small granularity of discretionary access rights, only dividing between read, write and execute rights for file owner, and file group members.
  
-=== Trusting the user's discretion for access control ? ===+==== Trusting the user's discretion for access control ? ====
  
 The fact that access control relies on a file owner's discretion already leads to various problems, like the level of trust that has to be put in a user, the vulnerability from malware working on behalf of a user, and so on. Also, there is hardly any logging of user activities possible, making it even harder to detect malicious accesses. The fact that access control relies on a file owner's discretion already leads to various problems, like the level of trust that has to be put in a user, the vulnerability from malware working on behalf of a user, and so on. Also, there is hardly any logging of user activities possible, making it even harder to detect malicious accesses.
  
-=== root, all powers into one account === +==== root, all powers into one account ====
  
 Another problem is the system administrator account "root". Many system tasks are only allowed to be done by this user, even many network services have to be started or, worse, run as root. The root account, however, has full access to every object in the system. It is easy to understand why so many Unix family systems have been compromised locally or by remote access. Another problem is the system administrator account "root". Many system tasks are only allowed to be done by this user, even many network services have to be started or, worse, run as root. The root account, however, has full access to every object in the system. It is easy to understand why so many Unix family systems have been compromised locally or by remote access.
Line 31: Line 33:
 However, while these capabilities can distinguish between some access types, they are mostly ignorant of the object that is to be accessed, for example ''CAP_DAC_OVERRIDE'' (capacity to override the filesystem access control) gives full read and write access to all files and devices on the system. As a result, many administration tasks still have to be done with too many access rights. Another disadvantage is the fixed access control model, which cannot easily be changed or replaced. However, while these capabilities can distinguish between some access types, they are mostly ignorant of the object that is to be accessed, for example ''CAP_DAC_OVERRIDE'' (capacity to override the filesystem access control) gives full read and write access to all files and devices on the system. As a result, many administration tasks still have to be done with too many access rights. Another disadvantage is the fixed access control model, which cannot easily be changed or replaced.
  
-=== The solution ===+==== The solution ====
  
 The RSBAC framework gives detailed access control information, and you can implement almost any access control model in it, e.g. as a runtime registered kernel module. Also, there is a powerful logging system which makes intrusion attempts easily detectable. The RSBAC framework gives detailed access control information, and you can implement almost any access control model in it, e.g. as a runtime registered kernel module. Also, there is a powerful logging system which makes intrusion attempts easily detectable.
Line 39: Line 41:
 RSBAC is a flexible, powerful and fast ([[documentation:benchmarks|low overhead]]) open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a). All development is independent of governments and big companies, and no existing access control code has been reused. RSBAC is a flexible, powerful and fast ([[documentation:benchmarks|low overhead]]) open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a). All development is independent of governments and big companies, and no existing access control code has been reused.
  
-Practically, it allows full fine grained control over objects (files, processes, users, devices, etc.), memory execution prevention (PaX, NX), real time integrated virus detection, and much more.+Practically, it allows full fine grained control over objects (files, processes, users, devices, network, etc.), memory execution prevention (MPROTECT), real time integrated virus detection, and much more.
  
 ==== What does flexible mean ? ==== ==== What does flexible mean ? ====
Line 48: Line 50:
   * [[wp>Mandatory_access_control|MAC]]: Mandatory Access Control   * [[wp>Mandatory_access_control|MAC]]: Mandatory Access Control
   * [[wp>Access_control_list|ACL]]: Access Control Lists   * [[wp>Access_control_list|ACL]]: Access Control Lists
-  * [[http://www.dazuko.org/|DAZ]]: Antivirus Scanner Interface +  * [[documentation:rsbac_handbook:security_models#role_compatibility_rc|RC]]: Role Compatibility
-  * [[documentation:different_models#role_compatibility_rc|RC]]: Role Compatibility+
  
-//To get a list and explanation of every model included in RSBAC, see the [[documentation:different_models|different models]] documentation.//+//To get a list and explanation of every model included in RSBAC, see the [[documentation:rsbac_handbook:security_models|Security Models]] section of the handbook.// 
 + 
 +{{documentation:rsbac_handbook:architecture_implementation:functional_diagram_gfac_rsbac2.png|}}
  
 RSBAC framework logic is based on the work done for the Generalized Framework for Access Control ([[http://www.acsa-admin.org/secshelf/book001/09.pdf|GFAC]]) by Abrams and LaPadula. RSBAC framework logic is based on the work done for the Generalized Framework for Access Control ([[http://www.acsa-admin.org/secshelf/book001/09.pdf|GFAC]]) by Abrams and LaPadula.
 All security relevant system calls are extended by security enforcement code. This code calls the central decision component, which in turn calls all active decision modules (the different modules implementing different security models) and generates a combined final decision. This decision is then enforced by the system call extensions. All security relevant system calls are extended by security enforcement code. This code calls the central decision component, which in turn calls all active decision modules (the different modules implementing different security models) and generates a combined final decision. This decision is then enforced by the system call extensions.
  
-Decisions are based on the type of access (request type), the access target and on the values of attributes attached to the subject calling and to the target to be accessed. Additional independent attributes can be used by individual modules, e.g. the privacy module (PM). All attributes are stored in fully protected directories, one on each mounted device. Thus changes to attributes require special system calls provided.+Decisions are based on the type of access (request type), the access target and on the values of attributes attached to the subject calling and to the target to be accessed. Additional independent attributes can be used by individual modules, e.g. the Role Compatibility module (RC). All attributes are stored in fully protected directories, one on each mounted device. Thus changes to attributes require special system calls provided.
  
 As all types of access decisions are based on general decision requests, many different security policies can be implemented as a decision module. Apart from the builtin models, the optional Module Registration (REG) allows for registration of additional, individual decision modules at runtime. As all types of access decisions are based on general decision requests, many different security policies can be implemented as a decision module. Apart from the builtin models, the optional Module Registration (REG) allows for registration of additional, individual decision modules at runtime.
Line 69: Line 72:
  
 //A general goal of RSBAC design has been to some day reach (obsolete) Orange Book ([[http://csrc.nist.gov/publications/history/dod85.pdf|TCSEC]]) B1 level. Now it is mostly targeting to be useful as secure and multi-purposed networked system, with special interest in firewalls.// //A general goal of RSBAC design has been to some day reach (obsolete) Orange Book ([[http://csrc.nist.gov/publications/history/dod85.pdf|TCSEC]]) B1 level. Now it is mostly targeting to be useful as secure and multi-purposed networked system, with special interest in firewalls.//
 +
 +//Note: this page is also part of the [[:documentation:rsbac_handbook|RSBAC Handbook]]//
//
why.1141296481.txt.gz · Last modified: 2006/05/02 13:40 (external edit)

why.1141296481.txt.gz · Last modified: 2006/05/02 13:40 (external edit)
This website is kindly hosted by m-privacy