RSBAC 1.2.3 includes the following models:
The Bell and La Padula Model describes access by active entities, called subjects, to passive entities, called objects. One entity can, depending on type of access, be in both roles.
From the distinction between read and write access four modes of access can be distinguished: neither read nor write (execute, e), read only (read, r), write only (append, a) and read-write (write, w). The set of all access types is named A.
Each current access of a subject Si to an object Oj in mode x is treated as a triple (Si, Oj, x). All these triples together form the set of current accesses b.
Objects are structured according to the Father-Son-Principle and build a hierarchy H of one or more hierarchically ordered, independent trees.
All authorized accesses of all subjects to all objects are held in the matrix M. Each cell Mi,j of M thus contains a subset of A with authorized accesses of Si to Oj.
A security level is a pair (Security Classification, Set of Categories). A security classification is a value out of a hierarchy, e.g. public, confidential, secret, top secret. A category is a formal assignment to a work area.
One entity with security level (S1,C1) dominates another entity with (S2,C2), if S1>=S2 and C1 is a superset of C2. The property dominates over all entities builds a partial order D.
The assignment of security levels to subjects and objects, the classification function F, is a triple (fS, fO, fC) of security level assignment functions. fS(Si) is the maximum security level of subject Si, fO(Oj) the security level of object Oj and fC(Si) the current security level of subject Si. Thus for subjects maximum and current security level are distinguished.
For all Si fS(Si) must always dominate fC(Si).
A state z of the model is a tuple (b, M, F, H). A system is a sequence of (request, decision, next state) with initial state z0.
The first property to be maintained is the simple security property (no read-up). This property states that a subject Si may have read access to an object Oj ((Si,Oj,r) or (Si,Oj,w) is a current access), if Si dominates Oj.
Figure 1: Illegal information flow in Bell-La Padula model.
To prevent copying of an object to a lower security level by a malicious subject, the *-property (no-write-down) must be maintained. This property states: If a subject Si has current read access to an object O1 and current write access to an object O2, then O1 must be dominated by O2 (O1 has a lower security level than O2). Thus information flow is restricted to upwards.
As a strict accordance to the *-property would significantly reduce the usability of the system, some subjects can be marked as trusted subjects without *-property restriction.
Access control by the matrix M of authorized accesses by subjects to objects is called discretionary access control, its security property is called ds-property. The current access must always be in the set of authorized access in its matrix cell.
All properties and security levels must be mandatorily enforced by the system. Every property is added to the other ones and can never reduce system security. A state that fulfils all properties is called secure.
The three properties lead to the following rules for access control decisions:
A current access (Si,Oj,x) is only granted, if the following conditions are met:
To use the defined security system state transition functions are necessary. These functions must provably change a secure state to another secure state, according to the decision rules. So induction can be used to proof every reachable state to be secure.
A complete set of those functions can be as follows:
The Bell-La Padula model only treats confidentiality aspects. Integrity, availability and privacy of data are not protected. E.g., a subject on lowest security level can delete all data in all its categories, if it is not discretionally protected. Attacks like this can also happen without the user's knowledge, just think of malware or mistakes. Especially discretionary access control is liable to be attacked by malware.
The concept of trusted subjects which can only be implemented as users or user processes leads to further possibilities of attack by use of high level user accounts.
This model should only be used without additional protection, if confidentiality is the only issue or if data can be easily restored.
The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1. This operating system was developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC.
Unix System V/MLS implements the Bell-La Padula model with some smaller changes, e.g. the ds-property is replaced by Unix style access control. Security levels with classification categories are maintained, simple-security-property and *-property are enforced. In contrary to Bell-La Padula writing is only permitted on the same level.
Bell-La Padula defined four modes of access:
This Unix system adds ten more modes, which mostly cover parts of the above modes:
Subjects are processes, which inherit their owner's security level. Four types of objects are defined:
Request | Condition for access |
---|---|
R/S/E | S >= O |
W(O/A) | S = O |
C/L/U | S = Od |
St | S >= O |
Ch | S = O |
Ripc | S >= O |
Wipc | S = O |
K | S = O |
Figure 2: Access Control Conditions in System V/MLS
Figure 2 shows a summary of access control conditions. S means subject, O object, Od directory object and >= and = stand for dominates and has same level. Read and write on directories mean access to entries, open is not possible.
The Unix System V/MLS model has been changed to fit into the RSBAC access request scheme, which knows more than 30 types of access. Also, write-up is implemented in the original way, so that you can always write to all higher levels. From version 1.1.1 onwards, writing is only allowed on the same level.
Since administration depends on the role security officer, role based functions had to be added. These restrict all changes to the classification of subjects and objects and role assignments (setting of MAC attributes) to security officers.
The security_level attributes used in RSBAC are what is usually called security classifications. Categories, limited to a number of 64 for efficiency reasons, have been added in RSBAC 1.0.8. From 1.0.9b, the number of security_levels has been increased to 253 (0-252, 8 Bit minus 3 special values).
The current security level (classification) and the current category set of a process are automagically adjusted as needed, if the mac_auto flag is on, which is the default value. However, mac_auto is turned off as soon as the process actively sets its current level or category set.
*-property enforcement is done with upper and lower bounds, called min_write and max_read. These values are reset only on execution of another program, not at process forking/cloning time or closing of files, because only new execution empties the process memory space.
Please note that until version 1.1.0, all write accesses, e.g. creating a file in a DIR (CREATE on DIR target), lead to the min_write boundary to be adjusted. This can lead to very limited access. Therefore, from version 1.1.1 onwards, the once-only write accesses CREATE and DELETE do not adjust the min_write boundary, while MOUNT, APPEND_OPEN, READ_WRITE_OPEN, WRITE_OPEN and TRACE still do.
Devices are treated similar to files with security levels and categories, and all properties are enforced. However, these checks can be turned off (attribute mac_check), because the system might become unusable otherwise.
The MAC file/dir attributes security_level and mac_categories can be inherited from the parent dir. For the security level the value to indicate inheritance from parent is 5 (4 is used internally), for categories it is the empty set (all bits 0). From version 1.0.9b, the security_level special values have been raised by 249, now being 254 and 253.
Stanislav Ievlev and me added a MAC option called MAC-Light to make the MAC module easier to use. Changes are:
The MAC model should be used, if you need a conceptually proven model for confidentiality. However, it is quite difficult to use in a typical Linux environment.
The role based model of functional control assigns one role to each user, e.g. general user, security officer or system administrator. Every object gets a category, e.g. general, security or system object.
The security officer states which roles are compatible with which object categories, or in other words, users in which roles can access objects in which categories. The security system enforces these settings.
The file/dir/fifo attribute object_category can be inherited from the parent dir.
The functional control model can in the simple version that is implemented in RSBAC only protect system data and security relevant data, but it already enforces separation of duties between the two special roles. An extension to more and more flexible roles could build this to a strong model. Without distinction between different access modes this model should only be used as part of a combined system.
FC can be easily expressed with RC model, so it is kind of obsolete. The RC default settings are very similar to this model.
You should use this model only to get experience as a base for other, more powerful models.
This role based model protects data of type security information. Only users with role security officer get write access to those objects.
The file/dir attribute data_type can be inherited from the parent dir.
Like the functional control this model should only be used in combination with others. Otherwise the security relevant information can still be protected against tampering by system administrators, what is more than Unix style access control can.
SIM can be easily expressed with RC model, so it is kind of obsolete.
You should use this model only to get experience as a base for other, more powerful models.
This model was presented on the 17th National Computer Security Conference in Baltimore, USA, in 1994 by its developer Simone Fischer-Hübner. It follows the rules of the Federal German Privacy Law and the EU directive on privacy.
The model and its implementation in RSBAC are described in detail in our paper for NISS 98 Conference.
The model focus lies on privacy. Confidentiality, integrity and availability are maintained for personal data and transaction procedures by the definition of necessary accesses.
System control data like general settings or authentification information can only be protected by declaring them as personal data. If this is not possible for some data, they cannot be protected.
This model should be used for storage and processing of personal data. To protect system data without the administration overhead of treating them as personal data, another model, e.g. FC, SIM, RC or ACL, should be used.
Use PM model, if you want to process personal data and need adequate protection.
This is not really an access control model, but rather a system protection model against malware. Execution, reading and transmission of malware infected files can be prevented.
This model should be used, if data, especially programs, are transferred from other systems to prevent a widespread malware infection. However, only malware known by the scanner algorithm can be be detected. On Linux this is the bliss virus in variants A and B and a few DOS viruses. Platform independent macro or java viruses will have to be included later.
Currently, this is only a working demonstration model, because too few viruses are detected. However, it is rather simple to add more scan strings, if you want to. From version 1.2.0, there is a generic interface to add other scanning engines.
For more details see our paper on Approaches to Integrated Malware Detection and Avoidance (34K) for The Third Nordic Workshop on Secure IT Systems (Nordsec'98)
This model defines some access flags for files, fifos, symlinks and dirs. Currently, the following flags are supported:.
Flag | Checked for | Notes |
---|---|---|
execute_only | FILE, FIFO, SYMLINK | |
search_only | DIR | |
read_only | FILE, FIFO, SYMLINK, DIR | |
write_only | FILE, FIFO, SYMLINK | |
secure_delete | FILE | File is blanked on delete and truncate (ext2, ext3, msdos/vfat, minix only) |
no_execute | FILE | |
no_delete_or_rename | FILE, FIFO, SYMLINK, DIR | new in 1.1.1, not inherited |
append_only | FILE, FIFO, SYMLINK | new in 1.1.2, write accesses are limited to APPEND_OPEN and WRITE, read accesses are allowed |
add_inherited | FILE, FIFO, SYMLINK, DIR | not inherited |
These flags are checked on every access to the given target types. Only users in system_role 'security officer' can change the flags.
The add_inherited flag is special: If set, the parent dir's flags are added (or'd) to the target's own flags. Inheritance is on by default. Attention: the flags no_delete_or_rename and add_inherited cannot be inherited, they must always be set explicitely!
Please note that the attributes are independent from each other and restrictive: All attributes that are set are applied, e.g. execute_only and no_execute together (or read_only and write_only) lead to no access.
Flags that are only checked for some target types are ignored for the other ones. This can be used to set e.g. search_only and execute_only on a dir - you can SEARCH (not READ!) in the dir and EXECUTE files in it, but nothing else.
Example1: Set write_only on a logging dir. All log files created in that dir inherit the write_only flag, thus the log can never be read unless the flag is removed.
Example1b: Set append_only on a logging dir. All log files created in that dir inherit the append_only flag, thus the log can be read, but writing can only append to the file, unless the flag is removed. Add flag write_only, if the files should not be read either.
Example2: Set no_execute on /home. All executables below that dir inherit this flag, thus no user can execute files from her home directory, unless the flag is removed.
Example3: Set no_delete_or_rename on /home. User home dirs below can be added, removed and individually protected, but the parent dir /home cannot be moved or replaced to fake other home dirs for most users.
File Flags should be used, if you need global access settings which are valid for all users.
Attention: This is the description of a rather old RC version. Please go to the new description for recent RSBAC versions!
This is a powerful and flexible role based model. It defines 64 RC types for each target type (File/Dir, Device, Process, Inter Process Communication, System Control Data) and 64 RC roles to access them. The RC module has been added in RSBAC version 1.0.8.
Please also see the RC model description in the RC-Paper.
Each role entry has the following fields:
Role Entry Field | Type/Values | Description |
---|---|---|
name | string of 15 chars | Name of role |
role_comp | 64 bit vector | Compatible roles (1 Bit per role) = roles process may change to without chown (setuid) |
type_comp_fd | 64 bit vector | Compatible file/dir types (1 Bit per type) |
type_comp_dev | 64 bit vector | Compatible device types |
type_comp_process | 64 bit vector | Compatible process types |
type_comp_ipc | 64 bit vector | Compatible IPC types |
type_comp_scd | 64 bit vector | Compatible SCD types |
admin_type | none, system or role admin | Role for RC role/type administration |
def_fd_create_type | File/dir type number or special value | Type of new files/dirs |
def_process_create_type | Process type number or special value | Type of new (forked/cloned) processes |
def_process_chown_type | Process type number or special value | Type of process after a chown (setuid) |
def_process_execute_type | Process type number or special value | Type of process after execute (start of a new program) |
def_ipc_create_type | IPC type number or special flag | Type of new IPC channels |
The admin_type entry denotes the RC administration rights: none = none, system admin = read-only, role admin = full. They do not give any other access rights, this is done with compatibility settings only.
Type entries have name fields (15 char strings). Only file/dir type entries have an additional boolean value type_fd_need_secdel, which indicates a need of secure deletion/truncation of files of this type.
SCD types are fixed and represent one area of accessible system data each. They are also used for administration rights, like adding modules or setting system time. SCD compatibility means accessability of the SCD facility.
Each target apart from user targets gets a rc_type attribute to indicate its type. For files and dirs this field can hold the special value type_inherit_from parent to signal inheritance of the attribute.
User entries get an rc_def_role attribute, which is used to determine the process's initial role after each CHOWN (setuid).
Process entries also have an rc_role for the current role.
File/Dir entries have a field rc_force_role to specify a forced role, if this file is executed. This mechanism works similar to the setuid or setgid field in Unix file systems. The forced role can also have one of the special values.
The special values mentioned above are as follows:
Role Special Value | Meaning |
---|---|
role_inherit_user | use user's (process owner's) rc_def_role |
role_inherit_process | use current rc_role of process (keep role) |
role_inherit_parent | use current rc_role of parent dir or process |
Type Special Value | Meaning |
---|---|
type_inherit_process | use current rc_type of process (keep role) |
type_inherit_parent | use current rc_type of parent dir or process |
type_no_create | creation of process/IPC is not allowed |
type_no_execute | execution of other programs is not allowed |
type_use_new_role_def_create | for process chown (setuid): use def_process_create_type of the new role |
When started without role definitions, three pre-defined roles are set up: General User (0), Role Admin (1) and System Admin (2). The pre-defined role settings are derived from the hard-wired settings in the FC module.
When started without type definitions, one type per target is set up. This is the default type General, which is also used as default value for all type attributes.
As usual in RSBAC, user root (0) has rc_def_role 2 and user 400 has rc_def_role 1 as predefined value in the default useraci contained in the admin tool package.
Please note: The pre-defined roles are normal roles designed to get you going. They can be changed like all other roles! You may easily lock yourself out, if you change them without knowing exactly what you are doing.
Still, the maintenance mode will allow you to modify roles, if you turned maintenance support for RC policy data on at kernel configuration.
To be secure, test your configurations with different role numbers and use rc_copy_role to copy them, if necessary.
The older RC model has been much changed. Until v1.1.2, it defined 64 RC types for each target type (File/Dir, Device, Process, Inter Process Communication, System Control Data) and up to 64 RC roles to access them. The original RC module has been added in RSBAC version 1.0.8. From v1.2.0, the number of roles and types is only limited by their 32 bit interger index number and system resources.
RC is a role based model: Every user has a default role, which is inherited by all his/her processes. Based on the current role, access to objects of certain types is granted or denied. The role can be changed by a change of the process owner, by the process via system call (only "compatible" roles allowed) or by execution of a specially marked executable (using initial_role or force_role, need not be "compatible").
Creation of new objects is a special case in every access control model. Here, every role has entries for the types of new objects, as well as entries for type setting behaviour on execution and change of process owner. Additionally, all these entries have a "no_create" special value, which disallows such requests.
Please also see the detailed RC model description in the Nordsec 2002 RC-Paper.
Up to v1.1.2, each role entry has the following fields:
Role Entry Field | Type/Values | Description |
---|---|---|
name | string of 15 chars | Name of role |
role_comp | 64 bit vector | Compatible roles (1 Bit per role) = roles process may change to without chown (setuid) |
type_comp_fd | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible file/dir types by request types (1 Bit per type and request) = True/False value, which type may be accessed with which request |
type_comp_dev | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible device types by request types (1 Bit per type and request) |
type_comp_process | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible process types by request types (1 Bit per type and request) |
type_comp_ipc | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible process types by request types (1 Bit per type and request) |
type_comp_scd | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible SCD types by request types (1 Bit per type and request) |
admin_type | none, system or role admin | Role for RC role/type administration |
def_fd_create_type | File/dir type number or special value | Type of new files/dirs (use no_create to disallow creation, needs CREATE right for chosen type) |
def_process_create_type | Process type number or special value | Type of new (forked/cloned) processes (use no_create to disallow creation, needs CREATE right for chosen type) |
def_process_chown_type | Process type number or special value | Type of process after a chown (setuid) (use no_chown to disallow creation) |
def_process_execute_type | Process type number or special value | Type of process after execute (start of a new program) (use no_execute to disallow creation) |
def_ipc_create_type | IPC type number or special flag | Type of new IPC channels (use no_create to disallow creation, needs CREATE right for chosen type) |
From v1.2.0, all compatibility and admin/assign role settings are placed into separate list, but the other entries are unchanged. Also, NETDEV, NETOBJ and NETTEMP type compatibilities have been added to support the new network targets. From v1.2.3, there are also USER type compatibility settings, along with user type definitions and a default_user_create_type field, which will become useful with RSBAC based user management.
Version v1.2.3 also adds a role flag boot_role. The first role with this flag set is used to start the system. If no such role is available, the default role of user 0 (root) is used like in previous versions.
The admin_type entry denotes the global RC administration rights for roles, types and RC specific attributes: none = no access, system admin = read-only, role admin = full. They do not give any object access rights, this is done with compatibility settings only.
Type entries have name fields (15 char strings). Only file/dir type entries have an additional boolean value type_fd_need_secdel, which indicates a need of secure deletion/truncation of files of this type.
SCD types are fixed and represent one area of accessible system data each. They are also used for administration rights, currently only auth_administration. SCD compatibility means accessability of the SCD facility. Additionally, the special SCD target 'other' is used to control requests with target type NONE.
Each target apart from user targets gets a rc_type attribute to indicate its type. For files and dirs this field can hold the special value type_inherit_from parent to signal inheritance of the attribute.
User entries get an rc_def_role attribute, which is used to determine the process's initial role after each CHOWN (setuid).
Process entries also have an rc_role for the current role and a field rc_force_role to keep the executed program's rc_force_role value.
File/Dir entries have a field rc_force_role to specify a forced role, if this file is executed. This mechanism works similar to the setuid or setgid field in Unix file systems. The forced role can also have one of the special values (see below). The forced role value is copied into the process attributes for further use on CHOWN requests.
From version 1.1.2, FD entries also have a field rc_initial_role. This setting determines, which role will be used directly after start of execution. At the next setuid (CHANGE_OWNER on this process), it will be replaced by the value in rc_force_role.
rc_initial_role can also have the special (and default) value role_use_force_role, in which case the value from rc_force_role is also taken as initial value. This is the same behaviour as before this field was added.
For NETTEMP targets, there are two RC type entries: rc_type and rc_type_nt. rc_type is inherited to the NETOBJ targets covered by this template, rc_type_nt is used for access to the template itself.
The special values mentioned above are as follows:
Role Special Value | Meaning |
---|---|
role_inherit_user | use user's (process owner's) rc_def_role on CHOWN and EXECUTE (default forced role until 1.0.9a-pre2) |
role_inherit_process | keep current rc_role of process on CHOWN and EXECUTE |
role_inherit_parent | inherit value from parent object, e.g. parent DIR |
role_inherit_up_mixed | keep current rc_role of process on EXECUTE, but use new process owner's rc_def_role on CHOWN (default forced role from 1.0.9a-pre3) |
role_use_force_role | valid in rc_initial_role only, default value. Use the value from rc_force_role. |
Type Special Value | Meaning |
---|---|
type_inherit_process | use current rc_type of process (keep type) |
type_inherit_parent | use current rc_type of parent dir or process |
type_no_create | creation of process/file/dir/IPC is not allowed |
type_no_execute | execution of other programs is not allowed |
type_no_chown | change owner of process is not allowed |
type_use_new_role_def_create | for process chown (setuid): use def_process_create_type of the new role |
From version 1.2.1, the following behaviour can be turned off by the global kernel boot parameter rsbac_no_defaults, which is useful for complete restore of a previous configuration from a backup script.
When started without role definitions, five pre-defined roles are set up: General User (0), Role Admin (1), System Admin (2), Auditor (3) and Boot Role (999999). The first three pre-defined role settings have been derived from the hard-wired settings in the FC module.
When started without type definitions, three types per target are set up. These are the default type "General" (0), which is also used as default value for all type attributes, the type "Security" (1) and the type "System" (2). Only "General" is actually used in the default setting, but example compatibilities are set up for all types.
As usual in RSBAC, user root (0) has rc_def_role 2 and user 400 has rc_def_role 1 as predefined value in the default user ACI settings.
Please note: The pre-defined roles are normal roles designed to get you going. They can be changed like all other roles! You may easily lock yourself out, if you change them without knowing exactly what you are doing. It is mostly the best choice to copy a role first and modify the new one.
Still, maintenance and soft mode will allow you to modify roles, if you turned maintenance or soft mode support for RC policy on at kernel configuration.
To be safe, test your configurations with different role numbers and use rc_copy_role to copy them, if necessary.
To follow the least-privilege rule, you can make the default user role 0 a dummy and set the role for every user explicitely. This way nobody gains anything by adding new users.
From version 1.2.0, you can set time-to-live values for compatible admin and assign roles as well as for all type compatibility settings. After the given time, the entry is deleted and further access is denied.
You can set ttl values with parameters -t, -T and -D in rc_set_item admin tool.
Warning: All ttl settings depend on the correct system time. You should take special care that it is always correct, if you are using this feature!
Newer RC versions contain a sophisticated model of separation of duty. For this, the following additions have been made:
ADMIN: Set/delete name, set need_overwrite for FD types
ASSIGN: Assign this type to objects. You also need MODIFY_ATTRIBUTE on the old object type.
ACCESS_CONTROL: Change normal (old) access rights to this type for your administrated roles
SUPERVISOR: Change these new special rights to this type for your administrated roles.
If no role has SUPERVISOR right to a type, the separation is forever fixed (again unless booting Maint kernel, or someone still has old style admin-type Role-Admin)
This model should be used whenever subjects and objects can be easily grouped into roles and types, if you need a strong separation of duty, or if you need access control based on programs, not only on users. The role and type abstraction makes administration much easier than individual settings!
This module can be seen as a support module for all others. It restricts CHANGE_OWNER on process targets (setuid) for a process: the request is only granted, if the process has either the auth_may_setuid flag set or the target user ID is in its capability set. The auth_may_setuid flag and the capability set are inherited on execute from the program file.
In other words: No setuid() variant system call will be allowed for any process running any program, unless the process (e.g. inherited from the program file) has either the flag auth_may_setuid set or an AUTH capability for the target uid.
A program file's capabilities can be set, if all modules grant a MODIFY_ATTRIBUTE request for A_auth_add_f_cap or A_auth_remove_f_cap. Process capabilities can only be added by other processes that have the auth_may_set_cap flag set, which is also inherited from their executed file.
This way an enforcement of daemon based authentification is possible, as well as a restriction of system daemons to a set of user IDs.
WARNING: If enabled without a login program having auth_may_setuid or a capability set and without a capability setting daemon, you will not be able to login to your system! Use kernel parameter rsbac_auth_enable_login in emergencies or at the first boot to set auth_may_setuid for /bin/login.
With AUTH enabled, system daemons which setuid to a normal user account, like portmap, mysql or whatever, need an explicit capability to do so. They will only be able to use uids you granted.
All Processes have two auth flags: auth_may_setuid and auth_may_set_cap with the above meanings. These are inherited by all child processes.
All files have the same two flags, which replace those of the process on execute of the file.
Files and processes also have capability sets with the same inheritance rules. Adding to and removing from capability sets is restricted by different access control schemes for processes and files: process caps can be set by any process, which has the auth_may_set_flag set, whoever may be the owner of the process. File flags are set on behalf of users by any program.
Up to version 1.0.9a, file capability sets can have the special value 65533 (UID -3), which is replaced by the owner of the process at the time the set is copied (execute time). Thus the process can come back to the original user ID after changing it. This value has been changed to 4294967292 (-3 again) in version 1.0.9b, which supports 32 Bit user ids.
Initially, nothing is allowed. Thus you have to enable the login of an AUTH security officer (uid 400 by default), who can do everything necessary. This can also be done with a maintenance kernel, setting appropiate values for all program files involved.
As a shortcut, you can use the kernel parameter rsbac_auth_enable_login, which sets auth_may_setuid (full rights to change process owner) for /bin/login. This behaviour is hardcoded in the AUTH module data structures.
AUTH only restricts its administration, if this is enabled in the kernel configuration. Administration is limited to users with system_role security_officer, and all involved attributes are protected.
Every module can further restrict the AUTH administration, if it depends on proper authentification. See the configuration menu help pages for more info.
Administration is mostly based on the file and process attributes and the capability sets mentioned above. See instadm.htm for more details.
This model should always be used, because it controls which users can work on the system.All other models depend on proper user identification, which can be enforced with AUTH model.
Access Control Lists specify, which subject (user, RC role or ACL group) may access which object (of an object type) with which requests (usual RSBAC requests and ACL specials).
If there is no ACL entry for a subject at an object, the rights to the parent object are inherited. Inheritance can be restricted by inheritance masks.
On top of the inheritance hierarchy there is a default ACL for each object type (FILE, DIR, ...).
To change the ACL of an object, you need the special right Access Control for this object. The special right Forward allows to give somebody else the rights you have, but you cannot revoke them afterwards.
Special right Supervisor includes all other rights, can never be masked out (unless allowed in kernel configuration) and can only be set by users who already have it. This right is set for user 400 in those default ACLs, which cannot be successfully read from disk at boot time, e.g. because of new installation.
All object types are supported. IPC, USER and PROCESS objects only have the common default ACL, which is always inherited to all objects of this type - these objects are too short-lived to administrate useful individual ACLs.
As of version 1.0.9a, there are an unchangeable ACL group Everyone (group 0), which by definition contains all possible users, as well as user defined groups.
Group management allows every user to define global and private groups without restriction. Global groups can be used by every user, private ones only by the group owner. Also, the group owner is the only one allowed to add or remove group members or to change the group settings name, owner and type. Since the owner can be changed, groups are transferable (thus making them possibly unaccessible for the original owner). This feature might become optional in future releases, because it can be used for attacks.
Group rights are added to user and role rights. As there is no global group administrator, every user can do the job of maintaining a sensible group structure, e.g. user secoff.
Just to mention: Similarities to other PC network systems may not be accidential... ;-)
From version 1.2.0, you can set time-to-live values for all ACL entries and group memberships. After the given time, the entry is deleted and further access rights change according to the remaining settings.
You can set ttl values with parameters -t, -T and -D in the ACL admin tools or through rsbac_acl_menu and rsbac_acl_group_menu.
Warning: All ttl settings depend on the correct system time. You should take special care that it is always correct, if you are using this feature!
This model should be used whenever you have individual subjects and objects, which cannot easily be grouped into roles and types for RC model, or if you need strong (possibly discretionary) access control with individual user groups. However, individual ACLs can be confusing. Try to use time-to-live settings for all temporary changes.
In Linux kernels, all root special rights are grouped in so-called Posix Capabilities, e.g. for network administration or full file access. The RSBAC CAP module allows to define a minimum and maximum capability set for both users and programs. Program settings override user settings, and minimum settings override maximum settings.
This module can be used to
in the standard Linux way. It is thus the only RSBAC module which directly interferes with existing Linux access control.
This model should be used whenever you have to do something which is usually forbidden by standard Linux access control, or if you have to run a root daemon, but want to restrict its rights in the rough Posix capability scheme.
CAP is specially useful to give RSBAC administrators, who are not root, read access to all directories so that they can administrate there despite insufficient Linux access modes.
Note: If you only want to partially disable Linux access control for filesystem objects for all users, you might consider to use the generic RSBAC functionality provided for this purpose through the 'Allow disabling of Linux filesystem access control' kernel config option.
All Linux kernels provide the chroot system call to confine a process in a subdirectory. However, it still has all usual privileges, specially when run as root. Also, there are several ways to break out if the chroot environment.
The JAIL module provides a new call rsbac_jail, which makes a chroot call (with chdir("/")) and adds further restrictions on the calling process and all subprocesses. Some of these restrictions can be turned off by flags to the syscall or the rsbac_jail command line wrapper, these are marked with an * in the following list. The rsbac_jail system call also takes the allowed IP-Address for binding (may be 0.0.0.0 for any) as parameter.
From v1.2.3 onwards, both chroot and IP address limits are optional. This version also adds Linux capability restrictions and includes several fixes to jail processes even more effectively.
Processes in a jail may not:
The JAIL module provides a superset of the FreeBSD jail functionality (except individual kernel level hostnames).
All processes in jails are listed in /proc/rsbac-info/jails, if RSBAC proc support has been enabled.
Use this module for simple service encapsulation, where chroot environments are applicable, but insufficient. Please do not forget that filesystem objects within the environment must still be protected separately, e.g. with JAIL Linux capability restrictions or using another model. As usual, the JAIL module only places further restrictions, so all other modules can be used independently.
The Linux kernel allows to specify resource limits for processes, e.g. the amount of CPU time or memory to be used, or the number of processes allowed for the same user. Unfortunately, these settings cannot be administrated properly.
This module can be used to administrate Linux resource settings for both users and programs. They are defined as minimum and maximum values and get applied at execute and setuid time (CHANGE_OWNER on PROCESS targets). Default values for all users can be set at the special user ID 4294967292 (ALL_USERS in RSBAC).
The RES module should be used whenever you want to set resource limits mandatorily.
The PaX or Pageexec kernel security extension contains several measures against usual ways of attacks on programs, e.g. by separating code and data areas and randomizing memory map addresses. In standard PaX, exceptions from these checks can be specified in the program header.
This module can be used to administrate PaX flags in a RSBAC consistent way and with a central backup facility. The RSBAC based settings do not touch the program file, so they avoid integrity checker alarms, missing flags on program updates and, most important, write accesses to binaries.
When using the module, make sure to disable header markings and to enable ACL hooks in PaX kernel config. More PaX information and the PaX patches are available from the PaX homepage at http://pax.grsecurity.net.
This module should be used whenever the PaX extension is used, too.
To top of page
15-Jun-04, -ao